Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
• Руководство по стилю: https://docs.godotengine.org/ru/stable/tutorials/scripting/gdscript/gdscript_styleguide.html
• Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
• Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
• Новости движка: https://godotengine.org/news/
• FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
• Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
• Играть в игродела онлайн без регистрации: https://editor.godotengine.org/releases/latest/ с дивана нельзя.
• Игры, созданные глобальными кириллами: https://steamdb.info/tech/Engine/Godot/ https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
• Изумительный Годот: https://github.com/Calinou/awesome-godot https://github.com/godotengine/awesome-godot - подборка дополнений, модулей и минишоукейc.
• Аддон для диалоговой системы: https://godotengine.org/asset-library/asset/833
• Прекомпилер шейдеров: https://godotengine.org/asset-library/asset/977 С версии 3.5 больше не нужен.
• Библиотека готовых шейдеров: https://godotshaders.com
• Майндмаппинг проектов не отходя от кассы: https://godotengine.org/asset-library/asset/879
• SmartShape для рисования 2D-террейнов без задней мысли: https://godotengine.org/asset-library/asset/715
• HeightmapTerrain для рисования 3D-террейнов без задней мысли: https://godotengine.org/asset-library/asset/231
• Конвертор кваковских карт для ностальгирующих дидов: https://godotengine.org/asset-library/asset/446
• Конвертер блендеровских моделей в формат сцен: https://docs.godotengine.org/en/stable/getting_started/workflow/assets/escn_exporter/index.html
• Конвертер блендеровских файлов прямо в движок: https://github.com/V-Sekai/godot-blender Надо только в настройках проекта путь к blender.exe указать. Потом просто закидываешь .blend в папку и импортируется.
• Godot Game Tools - GGT https://viniguerrero.itch.io/godot-game-tools
• Туториал по шейдерам: https://github.com/Volkovina/GLES-2.0-2D-Fragment-Shader-Tutorial-Series-in-Godot-Beginner-to-Advanced ГЛЕС2, да, но ты сначала БАЗУ выучи, ёпт!
Для любителей пощекотать конпеляцию
• Реализация ECS для Годота: https://github.com/GodotECS/godex
• Воксельные террейны от Зилана: https://github.com/Zylann/godot_voxel
• Поддержка различных языков: https://github.com/Vivraan/godot-lang-support
Годнота от анона
• Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе). Тут нужно отметить, что проект не запустится без папки .import и файлов в нём. Если попытаться запустить без неё, Godot попросит запустить редактор, чтобы импортировать ресурсы заново. Т.е., к сожалению, невозможно просто отредактировать текстуру в пейнте и увидеть изменения в игре - в любом случае потребуется запускать редактор, чтобы он импортировал текстуру заново, потому что импорт - это конвертация во внутренний формат (etc/etc2/s3tc/bptc), а оригинальный файл (.png, .jpg и т.д.) игрой не читается (load("res://icon.png") грузит версию из папки импорта, а не ту, что мы ожидаем).
• В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
• Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
Предыдущий: >>867751 (OP)
Архивный: >>852131 (OP)
https://youtu.be/EmQBLxxPV3E
Переводим предпочитаемой нейросетью. У кого своя мясная на инглиш заточена, а у кого электронная из интернетов.
>Переводим предпочитаемой нейросетью
>мясная на инглиш заточена
Похоже, ты только один язык знаешь, поэтому поясню лично для тебя: когда человек изучает второй язык, ему больше не нужно переводить с этого второго языка на свой родной. Твоё восприятие перестраивается и ты начинаешь понимать текст и речь на другом языке точно так же, как на родном, без перевода с языка на язык. Если ещё и говорить на втором языке научишься, то точно так же просто говоришь на втором языке, а не переводишь с родного на чужой. Второй язык врастает в тебя настолько, что ты можешь размышлять на этом втором языке, ведя внутренний диалог на нём без перевода на родной. В это тяжело поверить, когда ты ни одного языка кроме родного не знаешь, но на практике для такого уровня освоения не нужно даже обладать богатым набором слов; я по-прежнему вынужден иногда обращаться к словарю с некоторыми незнакомыми словами и путаюсь при построении предложений, но в пределах знакомых слов всё ощущается почти так же естественно, как родной русский. Переводчики, кстати, так и переводят - сначала они понимают суть сказанного на одном языке, как если бы это была родная для них речь, а потом выражают это своими словами на другом языке, опять же как если бы это был родной язык. Поэтому автоматические переводчики дико фейлились до прихода алгоритмов, способных отделить суть текста от конкретных слов и языковых правил, а затем описать эту суть словами и правилами другого языка - ранние переводчики переводили текст дословно без понимания сути и поэтому результат был очень далёк от желаемого, суть текста легко терялась.
Алсо, сегодня как нельзя проще изучить новый язык благодаря этим нейросетевым чатботам, т.к. они знают язык лучше онлайн-переводчиков и могут выполнять роль учителя языка. Пусть у них большая проблема с памятью и ограниченным контекстом, но изображать общение с носителем языка у них получается вполне достойно, так что как минимум тренировать текстовое общение на чужом для тебя языке с ними можно. Главное не воспринимать слишком буквально, они часто бред выдумывают, даже если формально всё правильно написано.
Прости за оффтоп, но ты триггернул меня.
получал "3" за присутствие на английском в школе, полностью забив на него, изучил язык по играм и руководствам к различным техническим штукам
>Твоё восприятие перестраивается и ты начинаешь понимать текст и речь на другом языке точно так же, как на родном
Сильно зависит от контента, видос ОПа я понимаю спокойно, но вот например в сериалах/фильмах все говорят как уебаны дегроды и нихуя не понятно вообще.
Ты что такой душный? Очевидно же, ОП выразился так, потому что прикольная аналогия, типа нейронка цифровая, нейронка мясная, йоу. Просто фигура речи же. Ты б ещё приебался к тому, что мясная нейронка вообще-то не состоит из мышечной ткани, а значит не может называться мясной.
https://youtu.be/vdAwlI6NG0I
https://youtu.be/XduuHNOGGqI
возвращайся в загон, и называй себя там как хочешь. Здесь твой тупой форс не пройдет.
Выступление ГДКвеста:
https://youtu.be/ZRFv2rTJLUY
Не, вот этот хуй душный. Да ещё гундосый. Дропнул просмотр.
>>873504
Карочи, по пунктам. Фичи пилятся. Всё будет уже в этом году. Начинаем пилить прототипы игор. К релизу ваших игор подтянется 4.5. Если ты ждал момента, когда начать, этот момент - СЕЙЧАС.
Они взяли курс на нативную интеграцию с блендером и другими опенсорцами в открытую экосистему. Такшта забей на встроенный %редакторнейм%, просто укажи путь к блендеру в настройках большого редактора и юзай бленд-файлы как сцены. Речь о четвёрке.
Чекнул игры с видоса, вообще ноль прироста по графикам, какая же залупа этот GDC.
>ноль прироста по графикам,
В смысле в по графикам стима, пользователи не прибавились, вот что я имел в виду.
>ноль прироста
У годота чот патреон тоже не растет, когда-то кажется под двадцатку был
Практика говорит об обратном. Бывают полностью нулевые игры, которые собирают миллионы, потому что в них вбухана куча рекалмы. Бывают норм игры, которые собирают десяток отзывов.
> Бывают полностью нулевые игры, которые собирают миллионы
Пруф.
В гугл плей зайди и там увидишь какого нибудь бегущего гиганта.
Ты в этого бегущего гиганта пробовал играть сам или чисто по пикчам ощущаешь, что игра нулёвая?
Да это вообще не игра. Как и прочие подобные. Там еще была игра где ты просто нажимаешь 1 кнопку и тебе показывают как будто ты выиграл баксы.
Не,надо ждать 4.5
Тогда все отполируют и гайдов будет уже много
Нахуя тебе гайды именно по 4-ке? Что с тобой не так? Я могу открыть гайд со знаменитого сайта про гейм-паттерны и прямо оттуда хуярить код в годот, на лету переводя из сиобразного псевдокода в гдскрипт. Почему ты так не можешь? Почему тебе требуется, чтобы тебе всё разжёвывали по 300 раз?
Пиздец. пытаюсь вкуривать вот этот туториал, но ощущение, что просто повторяю, как макака. Есть что-то более упрощенное? Этот кажется слишком перегруженным для небольшого проекта
> Есть что-то более упрощенное?
От пети сканера туториалы глянь. Заодно и по русски будет.
https://www.youtube.com/watch?v=ypqD5X0Nv78
>emit_signal: Error calling method from signal 'my_signal': 'Node(foo.gd)::bar': Method not found..
Через поиск по файлам пытаюсь найти - нету. Я тот сигнал уже отовсюду выпилил, а он всё равно вызывается как-то где-то. Как найти, где именно? Раздражает ошибка.
Ну как обычно, стоило спросить, ответ нашёлся.
Открыл подозреваемую сцену, и там мне ошибка жёлтым показывает, какая именно нода её вызывает. Оказывается, то был не мой сигнал, а встроенный с таким же именем.
Мне развитие строгой типизации очень нравится, хотя и 3.5 достаточно
Да ты прям как математик посчитавший овец в анекдоте.
Я в блендере и сам сейчас с ними работаю, только результат то экспортируется одним куском.
А тут можно:
- если будет рантайм поддержка, процедурно генерировать на лету.
- можно прикрутить оптимизацию мультимешем. Например если у тебя домики расставляются, или подоконники на них, ит.д.
Репорт.
А мы тем временем продолжаем учить рут мовшон
https://youtu.be/fq0hR2tIsRk
Мне нужна, я сам собирался делать, а сейчас увидел что он делает и ему помогают. То есть уже минимум 3 людям нужна. Чини свою логику, в общем.
https://youtube.com/watch?v=wdWIKuQ9b14
https://github.com/fernandolv33/lowpoly-chmaker
Хорошо, конечно. А там будут:
1. Геологическое моделирование
1.1. Ветряная эррозия
1.2. Жидкостные эррозии
1.2.1. Водные
1.2.2. Лавовые
1.3. Слои породы
1.4. Заполнение чанка водой с формированием озёр и рек, стекающих к уровню океана.
1.4.1. "Пляжная" эррозия - формирование пляжей на основе карты воды, созданной в 1.4.
2. Булевы операции.
3. Эквалайзеры.
4. Корорайзеры.
5. Формирование карт-масок с выходными данными на каждом этапе.
5.1. Сплатмапы заполнения поверхностей.
Если будет всё это бесплатно-опенсорсно, это будет просто охуенчик. И тогда останется один вопрос:
6. А там будет процедурная состыковка сгенерированного террейна между чанками (тайлами)? Бесплатно?
Не знаю пока, возможно и будет. Но вообще на многое из этого я видел алгоритмы и код, так что даже если есть только хейтмап, это все реализуемо.
Хочу вкатить после юньки, на сколько разница большая в интерфейсах и скриптах?
На 2д платформер по времени +- сколько уйдёт чтоб разобраться в архитектуре и тому как что лучше делать?
Доки, примеры, так же всё в гугле пишется и без гемора находится?
> на сколько разница большая в интерфейсах и скриптах?
В зависимости от твоего расположения на кривой гауссового распределения функции Даннинга-Крюгера, разница может быть как кардинальной так и незначительной.
Если попроще, то в обоих движках есть майнлуп с коллбэками, векторы есть, линейная алгебра реализована, в этом совпадает. Но по организации объектной системы, в юнити используется композитный подход (есть только один объект и куча компонентов к нему), а в годо используется наследуемый подход (есть много объектов, наследующихся от главного объекта, выполняющих свои задачи). Однако композитный подход не запрещен.
> На 2д платформер по времени +- сколько уйдёт чтоб разобраться в архитектуре и тому как что лучше делать?
Рабочий день.
> Доки, примеры, так же всё в гугле пишется и без гемора находится?
Всё есть. Всё как в шапке написано.
год-полтора, если сравнивать сколько шла разработка аналогичных в 3-ке.
ебать видос пропердывается. вроде у автора 60 фпс, а запись лагает пизда, че за хуйня, че за инвалид там это реализовывает, походу после него еще тонную фиксанов нужно будет делать
Очевидно, Годо человек осилил, а вот видео-кодировщик не осилил.
>Прекомпилер шейдеров: https://godotengine.org/asset-library/asset/977 С версии 3.5 больше не нужен.
А вот и не угадали. Я сейчас пилю экспорт в веб (то что в 4-ке называется Compability render), а там же старый добрый OpenGL, и что ты думаешь, пришлось стряхивать пыль с аддона. Благо что годот сам сконвертировал .tscn и .gd и все само заработало (я для этого создаю новый проект в 3-ке, кидаю в него то что хочу сконвертировать и открываю 4-кой)
В настоящий момент именно тормозит, поскольку ждет реализации определенной фичи в самом годоте - какминиму частичную перерисовку текстур. https://github.com/godotengine/godot-proposals/issues/6121#issuecomment-1496340232
> создаю новый проект в 3-ке, кидаю в него то что хочу сконвертировать и открываю 4-кой
А вот это достойно пойти в шапку! Схоронил!
На самом деле можно это делать из командной строки но как то лень обычно
https://docs.godotengine.org/en/stable/tutorials/migrating/upgrading_to_godot_4.html#using-the-command-line
Алсо это не серебряная пуля, оно не все конвертирует, чем меньше и проще проект, тем выше шансы. По ссылке так же написано как фиксить некоторые вещи которые сами не сконвертились.
Не подскажите, как можно подключить шейдер через код, а не через редактор?
у объекта есть материал, material_override, set_surface_material или что нить подобное, ему присваиваешь загруженный шейдер.
Примерно так
var shader_material = ShaderMaterial.new()
shader_material.shader = load("...shader")
mesh_instance.material_override = shader_material
либо
var surface_index := 0
mesh_instance.mesh.surface_set_material(surface_index, shader_material)
Есть, не пробовал, есть некоторые сомнения насчет них. Видел что есть подключение к openAI, но там платные запросы к API, и во вторых, chatgpt 3 учился на старых материалах, он вряд ли напишет под годот 4, а что умеет гуглить chatgpt 4 я хз.
В шапке стало слишком много ссылок. Что делать будем? Я тут погуглил, есть сервисы хранения ссылок. С одним из таких сервисов шапка будет выглядеть как-то так:
Добро пожаловать в тред любви, взаимопомощи и ...!
Шапка: https://hipolink.me/godothread
Предыдущий:
Архивный:
Норм? Ништяк? Да? Не?
Можно как-нибудь отключить управление мышью в itemlist?
может кто видел уже готовый ассет? пока думаю делать разделение мира на квадраты, где ближайшие к игроку будут подгружаться
>анонасы, а я смогу на данном движке сделать большой не рандомизированный 2D мир
Ты не сможешь
Ты на реализацию чарков потратишь много времени, готовых решений нет, есть отдельные куски демок и видео от васянов зарубежных, где это реализовано. Если готов потратить месяцок на чанки, то милости прошу, пробуй.
>Ты на реализацию чарков потратишь много времени
В 2д? Минут 15 на прикручивание массива к zone loader?
Пока ходил наливать чай, уже придумал решение на 10 минут для новичка. Называем сцены Chunk1c1, по периметру расставляем Area которые загружают сцены ChunkXcY, где X к примеру текущий + 2. Текущий получать в скрипте распарсив имя сцены.
Можно сделать 1 сцену-префаб и рисовать потом все на основе этой.
Ля какая красота!
Не сижу на годоте, просто захаживаю почитать тред, а тут такое!
Расскажи сложно и бесплатно замутить такую страничку? С радостью бы сделал такие шапки для пары тредов. И почему раньше до этого никто не додумался?
>Не сижу на годоте
Дык присаживайся
> Расскажи сложно и бесплатно замутить такую страничку?
Просто перейди там по основному адресу. Всё бесплатно, без смс, но с регистрацией, без этого никуда. Иначе как ты будешь изменения изменять на своей странице.
Просто будь внимательнее.
> Нормально ли
Вполне. Главное - удобство.
а не проще все в облаке держать?
гугл дает 15 гб
яндекс 10 гб
+ для мелочевки дропбокс юзаю, там 2 гб всего
На все хватает пока что
А вдруг у него гтаскайрим на 300 гигов одних только рабочих файлов? А? А???
Да я раньше, когда на юнити сидел, на Гугл проекты бэкапил. Потом гугл изменил программу синхронизации, что то там перенастраивать надо было. И я подумал, надо на своих дисках все держать, потому что сторонний сервис может внезапно прикрыть лавочку. Наверно вернусь к гугл диску.
Но меня все равно буспокоит, что это за баг у меня вылез. И не могу ли я похерить проект, тупо копируя все новые файлы с одного компа на другой? Может там какие-то служебные файлы копировать не надо.
Надо смотреть в сторону Syncthing + rclone или подобных вариантов. Т.е. опен сорсная прога делает бэкапы в любые доступные облака, причем с возможностью шифрования, чтобы твои ценные ассеты не утащили.
https://youtu.be/G_seJ2Yg1GA
Импортнул из блендера модель, хочу к материалу прицепить текстуру. Добавил SubViewport, в него канвас лейер с лейблом и цветным прямоугольником. Цепляю этот вьюпорт к вьюпорттекстуре нужного материала - он встает непонятно как и криво, а у челика из видео сразу как надо и заебись.
Что я не так делаб?
Просто квадратик в развертке был.
Кароч еще раз анврап сделал в блендере и заработало всё ок. Хз что это было
Требует напильника, т.к. ноги могут не заметить пол, и паук продолжает ползать по сфере, и наоборот, может пройти по полу сквозь сферу. Пока не знаю как исправить
Тут как то рисуют, правда там канвас шейдер - то есть 2д по плоскости?
https://godotshaders.com/?s=GRID
Да, там на плоскости рисуется перспектива. Но попробую посмотреть разобраться, может что-то там есть полезные техники.
Можешь попробовать рисовать при помощи MultiMeshInstance, я такую делаю при помощи него
Суть - создаёшь прямоугольник или даже параллелепипед, находишь его центр, находишь центр меду двумя крайними точками поверхности, затем туда перемещаешь его при помощи
multimesh.set_instance_transform_2d( _index, _transfo )
Затем растягиваешь на расстояние, равное половине расстояния между точками
Потом закрашиваешь
Непонятно как поддерживает сглаживание, у меня не получилось его врубить
Второй вариант есть Line2d, просто создаешь отдельные линии между двух точек и всё, поддерживает сглаживание
Так а просто текстура сетки не подходит? Тебе надо что то хитрое?
>>875653
Я писал шейдер, который на любой поверхности рисует сетку. Поэтому текстура не подойдет, отрисовка меша и линий тоже.
По нажатию на кнопку у меня меняется флаг.
А анимация происходит за счет постоянной проверки в _process(delta) значения и изменение флага.
Это же тупо. Есть другой подход?
>за счет постоянной проверки
В любом языке программирования и движке всегда плохо то что засунуто в ежекадровую обработку.
Идеал это вызываемая функция с событием. Всегда и везде надо стараться уменьшить количество кода который обрабатывается каждый кадр.
Да много вариантов
Например нарисовать нужное движение в AnimationPlayer
Или добавлять ноду с таким кодом только когда надо двигать.
Или, например, можно отключать process через set-process(false) и включать только когда надо
Но в конце концов если сделал как у тебя то ничего страшного - компьютер наверняка вывезет десятки тысяч таких кнопок.
Если желаешь советов по мелочи
Можно написать settings-show = not settings-show в одну строчку
Не стоит делать $"..", ведь можно один раз в ready() запомнить переменную par = get-parent()
Вообще вроде как считается не очень управлять родителем
Забавный факт - если ты переставишь родителя и ребенка, то все вообще обойдется просто position, т.к. ребенок и будет относительно родителя.
>set-process(false)
Воспользовался этим.
>Можно написать settings-show = not settings-show в одну строчку
Впихнул туда set_process(enable)
Вот тут нашлось, вроде играет, адср есть, формы есть, правда автор честно признался что там гумнокод, и лицензию не указал.
https://github.com/petterthowsen/epikus-8/tree/master/SFXer
>автор честно признался что там гумнокод
Ну да так-то. Код-то, в общем-то, норм, но весь на гдскрипте. А на гдскрипте я и сам могу. Так-то вопрос возник, потому что в доках пишут:
>AudioStreamGenerator
>Note: Due to performance constraints, this class is best used from C# or from a compiled language via GDNative. If you still want to use this class from GDScript, consider using a lower mix_rate such as 11,025 Hz or 22,050 Hz.
Из поста было непонятно что ты на гдскрипте и сам можешь и тебе нужно на чем то другом. Ну тут думаю тоже не проблема - принцип остается тем же, гдскрипт играет из буффера, а твой код формирует буффер - но тут можно поискать и на c# либы, и на с++, думаю там опций десяток будет - тебе же нужно просто заполнить массив, передав параметры ноты, это движконезависимая часть.
Но что если вместо того чтобы писать шейдер, мы с вами возьмем Gridmap и пользуясь данными heightmap заполним его кубами? А что если мы заполним его не кубами, а заранее заготовленными модельками булыжников? Кто-нибудь так делал?
Фишка готовых аддонов с террейном - готовые лоды, возможно клипмапы, а мультимеш и гридмап вроде бы не умеют в лоды и в окклюжен и там надо самому делать? Я правда давно с этим разбирался, пару лет назад. Кажется тогда надо было несколько мультимешей на разные лоды, и при этом обновлять данные когда персонаж подходит ближе.
Я на 4ке большой 3д проект пилю, но для браузера там тени пока не дописали. Ну и весить то билд побольше стал. Так что я хз даже, вроде как и можно делать навороченные 2д игры и даже простые 3д гиперкажуалки, но их с таким же успехом можно и на 3.6 делать.
> мультимеш и гридмап вроде бы не умеют в лоды и в окклюжен и там надо самому делать?
Вроде бы как раз умеют. Искаропки.
Я не опытен в этом, но у 3дмакса есть модификатор Multires, интересно как ты делаешь это, кроме автоматического варианта через годо
Сейчас никак не делаю, просто закинул модель и чуть необосрался. Раньше делал в 3 годоте как учили - несколько мешей вручную и переключал их скриптом по on area entered. Возможно тут так же придется, только переключать в 4ке лоды можно не вручную, а просто сделав одному объекту visibility range min-max до 5 метров, другому объекту от 4 метров до 10 и так далее.
> лоды можно не вручную, а просто сделав одному объекту visibility range min-max до 5 метров, другому объекту от 4 метров до 10 и так далее
О, годно
Я вот хотел бы сделать игру типа Lands Of Lore 2 с воксельными объектами вокруг при помощи grid mesh или как там его, вообще авторы годо очень хорошо придумали tilemap и gridmesh, ну и я был очень доволен MultiMeshInstance, по сравнению с подобным в OPenGL просто супер легко
Ну а что не кажуальное ты можешь придумать в 3д но без теней? Я то пилю с рассчетом что все таки хотя бы базовые тени допилят. Сейчас там просто иногда заливает все черными треугольниками.
Гридмеш поначалу вызывает радостные эмоции, но потом понимаешь что если ты хочешь сделать улицу под 30 градусов то легко не будет. Можно конечно попробовать гридмап на город или городской район и ставить под нужным углом. Еще я как то скидывал набор городских тайлов где уже заложены некие кривые улочки
Сделаешь тестовый проект? Я тоже могу, но сейчас пишу с картофелины, поэтому это может занять день.
>воксельные объекты
Потести, не уверен что потянет если ты хочешь использовать их как мелкие воксели.
Всем ку годотеры, подскажите, хочу сделать на годоте подобие игр на ренпи и куспе раньше которые были, но немного по приятнее визуально и не с такой лапшой кодом как там.
Сам геймплей игры прост до безобразия, есть пара фонов, десяток спрайтов персонажей, диалог как в новеллах с кнопками ответов, и разные интерфейсы окон, ничего в реалтайме не будет делаться, только ожидая нажатия от игрока.
Надеюсь понятно объяснил, такое сложно будет сделать и возможно?
Есть новелмейкер или типа того, это отдельная прога
А если годо, то ищи плагины чтобы не тратить время на создание всего этого и сразу делать твою задумку
У меня своя задумка, и стандартные новелкомейкеры не подойдут точно.
И плагины зачем? Всё сам хочу написать чтобы понимать как, что, куда идёт, она то на вид примитивная будет, но там много окон и взаимодействий, плагинами такое не реализовать.
Годаны, кто реализовывал свечение отдельных объектов в проектах? Про glow в world environment в курсе, но что-то получается сомнительно. Вот есть отдельная сцена с врагом (ареа, спрайт и колижн шейп), добавляю так свечение, в итоге вся основная сцена игры, когда появляется враг, начинает светиться, как новогодняя ёлка, и фон, и гг, и предметы.
2д? Так там вроде источники света есть. шейдеры опять же.
С другой стороны ты пишешь про ворлдэнвайр, он вроде только для 3д же. В 3д сложнее , в каком то прошлом треде обсуждали. Легко только со сферой.
Сделаю позже. Щас пока нет времени. Смотрю видосы, как правильно кидать топор https://youtu.be/6GIrjs-Qy0U
А рут моушн уже посмотрел? Стоит делать?
Смотря, какой гейплей у тебя задуман. Рутмовшон подходит для игор с минимумом вертикальности. Если у тебя много паркура, лазанья по стенам то рутмовшон не справится.
Все я вспомнил что это, это Animation-driven движения, да у меня планируется больше поркура, надо подумоть.
И взял этот ваш годот...В целом всё понятно, однако я неудачник и пришел к моменту выхода новой версии поэтому в интернете нихуя нет.
Собтвенно вопрос: Есть characterbody2d , беру и делаю scale.x = -1 и весь персонаж разворачивается. У меня всё работает. Однако в интернете есть полно обсуждений, что вешать негтитвное значение в scale для физических нод нельзя. Иначе всё идёт в жопу.
Но всё это датированно 2018-2022 годом.
Собственно сейчас в новом godot4 это пофикшенно, и физ ножам можно задавать отрицательный масштаб или я просто что то не так делаю?
Если у тебя персонаж - симметричная капсула или квадрат, тебе вообще не надо ее флипать. Тебе надо флипать только визуальный спрайт.
> Сделаю позже.
Идея прикольная, но почему-то 10 ФПС на объёме до 50,50,50 блоков. Если задавать объёмы больше - фепесы падают в нулину, блять. Без коллизий, без навмешей. Гридмап, блять. Оптимизированный октантами. Блять.
А можешь еще потестить лоды и оклюжн куллинг на гридмапе? У меня лапки, на нетбуке не работает вулкан, а в опенжоле не показывает.
Тут написано как потыкать в редакторе, но не факт что там точно измеряет
https://docs.godotengine.org/en/stable/tutorials/3d/mesh_lod.html#comparing-mesh-lod-visuals-and-performance
https://docs.godotengine.org/en/stable/tutorials/3d/occlusion_culling.html#previewing-occlusion-culling
Или попробовать по честному вкл-выкл окклюжн где-то в настройках проекта Rendering > Occlusion Culling > Use Occlusion Culling , а лоды галочкой в импорте модельки, как я кидал выше скрин.
И еще вопрос как вообще настроить лоды для элементов гридмапа. В свойствах самого гридмапа? В мешлибе?
Еще такая мысль - не знаю как у них сделана сортировка по объектам/материалам. Можешь попробовать еще сделать несколько гридмапов, но каждый в мешлибе содержит только один вид камня. Чтобы отрисовка точно шла одним батчем. Или вообще сравнить с мультимешем.
> но почему-то 10 ФПС
50 в кубе это 125 000, не факт что там используется instance render, хотя хрен его знает
Касаемо лод, тот тут менять в зависимости от расстояния
Очевидно же в свойствах материала есть emission, его и крути, с glow и вовсе становится балдеж
Emission сам по себе не производит свет, он просто делает участок текстуры видимым в темноте, даже если объект в тени. А глоу на всю сцену может быть нежелательным.
Нашел свой старый пост на тему с возможной эмуляцией >>850059 → >>850237 →
> вкл-выкл окклюжн где-то в настройках проекта Rendering > Occlusion Culling > Use Occlusion Culling
Включил. Немного фепсов прибавилось, но всё равно не продакшен-левел. Не впечатлило. Вот скрины с куллингом и одним кубом, в объёме 100/100/50 соответственно.
Если ты хочешь рядом все освещать, то явно с помощью узлов динамического света. емиссион жеж и при запечке учитывается, так что хуй знает че тебе еще надо. Да, можешь заюзать шейдер с прозрачным градиентом. На твоих пиках так же юзается емиссион, ток еще юзается дублированная геометрия, вдоль нормалей сдвиг и полупрозрачность
хз с чего ты решил что там эмиссия, в шейдере ее нет, а зеленый засвет на белой стене это действительно источник света. А дублированная геометрия слишком заметна в местах где она накладывается. По хорошему там надо что то с вьюпортами мутить, эмулировать стенсил буфер, но это долго и лень.
в 4 есть буфер глубины
в 3 есть костыли, с вьюпортом и камерой
Не до конца просто понимаю че ты хочешь сделать.
Когда у тебя будет сцена построена со светом, без емиссона у тя будет все блекло, пока это незаметно пока ты там чета ковыряешь вне законченной композиции с выставленным светом
Скайкрафт мечты! Мой майнрим!
Кстати анон, а не дохуя ли ты генеришь? Не производительней будет дохуя более мелких гридмапов 10х10х10, а не один 50х50х50?
Дело в том, что я не силён в математике. Если ты мне покажешь как сделать так, чтобы несколько гридов бесшовно принимали значения из одного шума, тогда сделою.
Сейчас у меня была главная идея в том, чтобы был один грид, один шум, одна карта. А грид чтобы сам куллился автоматически. Он же там как-то хитро на октанты разбит, которые якобы куллятся и лодятся автоматически?
Ты отвечаешь анону, который отвечал другому анону.
Что хочет тот анон не знаю, а мои эксперименты начались с того, как сделать световой меч АКА лайтсейбр, в виде цилиндра, и чтобы на сцене можно было иметь два с разным радиусом свечения (что через глоу ворлдэнвайр вроде невозможно)
>Если ты мне покажешь как сделать так, чтобы несколько гридов бесшовно принимали значения из одного шума, тогда сделою.
В смысле, ты этот шум по частям и генерь на каждый гридмап. Все тоже самое как у тебя, только ты берешь шум не с 0 до н-макс размера твоей текстуры шума, а н-заданое.
Например текстурка 256, а ты делишь все на 10, ну дык и дели 256 и получай значение каждого шага.
Так и так тебе нид разбивать все на сегменты, дабы их всегда можно было убрать из памяти\либо не рендерить и не напрягать комп.
говорю анон, покажи мне картинку того чо ты хочешь, рефы нужны. Описания хуйня, световые мечи как раз через емиссион и глоу делаются
>якобы куллятся и лодятся автоматически?
Мы так до конца в этом и не убедились. Тесты надо.
>октанты
По идее они и не помогут в случае 100 процентного заполнения объема, а только дадут оверхед. Ведь нарисовать надо все кубы, но при этом на каждый куб будут рассчеты. Октанты помогают в прореженной сетке, например если у тебя сеть дорог или хотя бы просто только поверхность террейна.
> как сделать так, чтобы несколько гридов бесшовно принимали значения из одного шума
Создать нойс в родительской ноде один раз и брать оттуда. А циклы проводить не от -25 до 25, а по частям.
ЯННП. Какая текстура? Я взаимодействую с шумом через встроенный интерфейс. Код выше посмотри. Я получаю значение шума не на текстуре, а прямо в пространстве, через .get_noise_3d(i,j,k)
> Тесты надо.
А вот собсна тест выше и был. Никакой оптимизации. ФПС на 10. Придётся всё таки юзать аддоны. А хотелось самостоятельно.
В общем-то я уже сам нашёл ответ, как объединить несколько "чанков" гридмапов под одним шумом. Надо добавлять координаты самого гридмапа к координатам в сетках. .get_noise_3d(pos.x + i,pos.y + j, pos.z + k)
Надо еще попробовать тупо мультмешинстанс, с расстановкой кубиков самому.
Сложна, сложна, нипанятна! Ниасиливаю. Раз 10 пытался разобраться. Безрезультатно.
и че? чем отличается от текстурки 2д ток в 3д? те же координаты, и их значения. бери и отрисовывай от 1,1,1 до 10,10,10 и т.д со смещением, то бишь координаты меняются со смешением и так раз за разом генерится
я юзал мультимеши для мульонов пуль + синхронизация с физик сервером, пара косарей пуль на изи генерится, постоянно можно пересчитывать, то бишь супер быстро работает на перечитывание. Базарю, анону рили стоит пробнуть мультимеши, а физику юзать напрямую через физик сервер
И кстати, я хочу отдельно заметить, что циклы в ready которые на скринах, выполняются очень быстро. Тормозит не вышеприведенный код, тормозит именно отрисовка готового статичного гридмапа.
Просто обидно, этот гридмап выглядит таким удобным, а по факту неюзабелен.
юзай мультимеши брат
>>875920
гридмапа какая-то хуета помоему не? у тебя дравкалов пиздец много. при мультимешах у тебя такой хуйни не будет. они еще и быстро перерисовываются.
если надо. могу найти код старый, мейби чета спиздишь оттуда для себя
Не сложнее чем твой код, сейчас показать не могу, но к вечеру может быть.
Было предложение его выпилить из 4-ки, но народ начал возмущаться. А по факту так и есть, он только совсем новичкам подходит которые собирают свою первую гташку по кварталам. Ну еще его можно юзать как массив для всякого астар, но можно и без этого обойтись.
Без теней +10 ФПС, но повторюсь, как же без теней-то в 2к23.
>>875926
> юзай мультимеши брат
Придётся разбираться.
>>875927
Окей. Ну я пока сам начну. Если что, потом сравним.
>>875928
Похоже на то.
>>875924
>>875918
https://pastebin.com/VgLu5GJH
создание в мультимеше, с физикой на физик сервере
Держите аноны, можете попичкать код, генерить любую н-хуйню, при желании в апи можете посмотреть другие виды капсул для колизии
Вызов функция вот, 1 значение вроде бы пакет сцены, на скрине показано что из себя представляет, оттуда берутся мешь все настройки для физик сервера
2 это координаты где будет спавнится
3 это исключения колизии, вроде нид указывать просто ссылку на просто объект аля rigidbody kinematic body и все, они будут исключатся и не будут сталкиват
4 это эффекты всякие при спавне, но я их не реализовал тогда
func projectile(packed_scene : PackedScene, spawn_transform : Transform, collision_exceptions := [], _effects := [])
сорян, мейби говнокод, но я это делал года 3 назад, я не шибко какой-то йобо кодер
аноны, пощупайте, если хотите
Алсо дополню. Я это юзал именно для спавна гильз дабы на сцене было их тысячи с коллизией и т.д, без пропуков. Вы же можете это оптимизировать для себя подругому, без нужды допустим чтобы они выплевывались с н-скоростью, а были сразу статик, короче там массу настроек можно сделать
На примере 3-ки.
Если менять Power в emission, меняется цвет свечения, но радиус остается тем же.
Если менять Intensity или Strength в Glow WorldEnvironment, то меняется интенсивность всего свечения - обоих мечей, фары мотоцикла, солнца, неба, аллаха.
Изобразил в 2д как я себе представляю желаемое. Также желательно например чтобы можно было анимировать радиус только одного из них.
Вулкан потестить сейчас возможности не имею, а в опенгл 4-ки Glow пока не сделан.
Добавлю, что в случае лайтсейбров, ламп дневного света, можно попробовать придумать что то вроде 3д спрайта в котором рисуется 2д текстура, все же овал не очень сложная форма, но с персонажами такое уже не прокатит.
А видимо все. больше вариантов не будет из стандартных. то бишь тебе придется развлекаться только со стандартным глоу, можно конечно в случае с персонажем в шейдере дублировать сетку и выдавить её по нормалям, накинуть емиссиона на это эффект, плюс с глоу поиграться дабы меньше переходов было видно. Я вот не помню, погляди в настройках, мейби там есть возможность увеличить качество глоу, а то оно у тебя рили рубленное.
Свечение лучше чем в этих видосах ты не сделаешь
https://www.youtube.com/watch?v=P-6NmnwbavY&ab_channel=GameDevChris
https://www.youtube.com/watch?v=-7jo5uUxwXE&t=5s&ab_channel=3rdMonkey
Анончик, ты просто охуенен!
> пощупайте, если хотите
Пощупал. Код зависит от синглтонов. Такшта либо тащи их, либо заведи полезную привычку описывать зависимости в комментах, чтобы сразу видеть самому от чего зависит код, либо не используй синглтоны (понимаю, сложно отказаться от удобства).
> либо не используй синглтоны
Не закончил мысль. Щас в туториалах на ютубе и как следствие в ассетах на ассетлибе, пошла мода вместо прописывания автолоада, прописывать export(NodePath) var в скриптах. Это явно показывает, что скрипту следует подсунуть правильную ноду для работы, и уже об этом не забудешь, и зависимость у кода будет явная.
> Код зависит от синглтонов
А, там физик delta из Global.time, дабы в простое Physics process не работал, или я даже хуй знает чем был мотивирован когда делал это, лол.
тащемта сорян анончик
>>875932
Сорян, я хуй знает зачем ваще этот синглотон захуярил туды, лол, он там не нужен, можете просто delta из physics_process вывести в в глобал переменную скрипта
>>875932
Вот еще вспомнил недавно обсуждали воксель модуль Зилана, может тебя заинтересовать >>871412 →
> может тебя заинтересовать
Надо же! Настоящий модуль воксельного террейна! Впервые вижу! Спасибо за помощь!
Очевидно же, что я пытался обойтись а) без вокселей, б) без сторонних модулей
Насчет б) насколько я понимаю стратегию развития, такие расширения будут только внешними. Но в этом случае модуль уже там скомпилирован в кастомный билд движка.
а) просто подумал, что раз ты делаешь типа воксели, то почему бы не попробовать воксели и сравнить производительность.
> скомпилирован в кастомный билд движка
Пора бы уже мне научиться билдить самому движок с любыми модулями, какие захочу.
А можно как-нибудь в версии 3.5 копировать коллизию тайлов? А то как-то запарно каждый раз заново её ставить
Не помню насчет нормального способа, но точно применял такие
1) генерировал скриптом на питоне файл с коллизиями, грубо говоря tscn же текстовый файл где можно по мелочи даже руками скопипастить
2) генерировал какие-то коллизии tool-скриптом, там конечно надо покурить api че кому назначать, но это реально, типа найти нужный тайл, взять его коллизию, назначить другому тайлу.
Может быть есть что-то даже готовое в ассетах, давно 2д не чекал.
Иногда да, я просто не люблю обезъянью работу, и если что то можно автоматизировать, я лучше час потрачу на тул скрипт, чтобы потом в любой момент копировать что-то, особенно если это надо повторить больше 16 раз. Редко конечно могу включить что то чилловое посмотреть в фоне и под это дело кликать. Но ска цена ошибки часто высока, приходится переделывать, возвращаться к пропущенным. Цикл в скрипте проще, если ошибся. просто правлю и еще раз прогоняю.
И еще на тему root motion. Есть сейчас акутальный плагин для blender+mixamo+godot? Раньше я знаю был Godot game tools, но он подглючивал, и вообще слабо поддерживается для актуальных версий блендера и годота, там куча ишью, и свежего форка не нашел чего то.
Порылся по топикам гитхаба и нашел такой https://github.com/baracil/Mixamo2Godot
Сейчас буду опробовать
революция близка
Делаешь руки отдельно от тела, анимируешь либо скелетной анимацией, либо просто кодом поворачиваешь спрайт рук, который висит чайлдом во всём теле
Тонна челов которые реализовывали подобный поворот оружия. Основная мысль в том, что у спрайта есть pivot и благодаря этому оружие вертится не от центра спрайта.
>на каждые ~10 градусов рисовать отдельный спрайт
Зато это красиво. Вообще сейчас есть способы ускорить этот процесс, рендерить в 3д, а еще нейронки.
>руки просто привязать к плечам и оружию, чтобы они болтались как сосиски, но не знаю как такое сделать в годот.
так ноды же вращаются относительно родительской.
Ты можешь вращать ее через rotation, а можешь сделать что то вроде $Gun.look_at( get_local_mouse_position() ) - на самом деле чуть сложнее, поскольку надо бы брать позицию мыши из камеры, уже с учетом масштаба и сдвига. Это вообще за 5 минут делается.
Или как анон выше сказал скелетную анимацию https://docs.godotengine.org/en/stable/tutorials/animation/2d_skeletons.html Но это уже позаебистее.
>Зато это красиво.
Вообще можно совмещать риксели и смену спрайтов. Но в большинстве игр вообще не парятся с этим.
>>876318
>Ты можешь вращать ее через rotation, а можешь сделать что то вроде $Gun.look_at( get_local_mouse_position() ) - на самом деле чуть сложнее, поскольку надо бы брать позицию мыши из камеры, уже с учетом масштаба и сдвига
У меня сейчас так и сделано. Я не понимаю как сделать так, чтобы один конец рук был всегда привязан к рукоятке оружия, а другие концы рук всегда был привязан к плечам. Было бы проще, если бы руки были одной длины и просто сделать их родительским объектом для оружья, но они у меня разной длины т.к. спрайт в ракурсе 3/4
Работает. Чуть чуть все таки пришлось доработать напильником.
Воркфлоу стал побыстрее чем раньше.
1. Подготовить модель, с ригом. Можно с несколькими мешами (одежда, отдельная голова...). Тут же я масштабирую до нужного роста (около 1 метр 80 см) и применяю все трансформы, чтобы потом не возиться. Также переименовываю кости, если у них какие то дурацкие названия. Можно написать простой скрипт, если надо убрать префиксы типа ModelName_Hips
2. Экспортировать в FBX. Чтобы в миксамо видеть текстуры, в блендере надо при экспорте выбрать Copy и нажать рядом иконку коробки (упаковать)
3. Скачать с миксамо нужные анимации. Там есть целые паки, можно и их. В отдельных анимациях, галочку In Place ставить не надо, раз мы хотим Root Motion
4. Закидываем желаемые анимации в папку, туда же кидаем TPose.fbx, переименовываем анимации как нам надо, добавляем -loop если хотим зацикливание (это можно потом при импорте в годоте поменять). Idle я не делаю зацикливание, так как хочу запускать рандомные, а для этого знать когда закончилась анимация.
5. Запускаем скрипт, он создает .glb названный по имени папки. Закидываем в Годот, настраиваем дерево анимаций, любуемся RootMotionView нодой.
6. Почему то часто glb импортирует материалы как прозрачные. Не понял как запретить. Исправляю так - в Годоте дабл клик на glb, открываются опции импорта. Там нажимаю action - export materials. Выбираю .res вместо .tres, иначе создаются какие то неадекватные материалы по 80Мб и сцена грузится полчаса. Все, теперь можно редактировать прозрачность в материалах отдельно.
Работы все равно дальше много, но скрипт позволяет пропустить все ручное прокликивание каждой анимации в блендере.
В чем заключался напильник для скрипта. Почему то все скрипты для миксамо подразумевают, что модель увеличится в 100 раз, поэтому анимацию уменьшают обратно в 100 раз. Но в моем случае с миксамо все скачалось один к одному как я заливал. Поэтому наоборот рут моушн топтался почти на месте. Решение - закомментировать в скрипте строчку которая делает скейл 0.01
Из непонятных технических моментов. Блендер при экспорте glb пишет что запекает анимации, потому что что то там не совпадает в кол-ве кейфреймов. Не знаю плохо ли что он запекает или пофигу. Еще предупреждает, что есть вершины, на которые влияет больше 4 костей (вроде так). Тоже не особо представляю стоит ли париться.
>У меня сейчас так и сделано
, но пока без анимации. Ноги и корпус стоят, ходят, бегают, а оружие просто в воздухе вращается
По идее тебе надо что-то вроде 2-chain inverse kinematic
Если я правильно понял твою проблему, что тебе надо чтобы одна рука в локте сгибалась.
Показывает историю, диффы, измененные файлы. Есть какая то поддержка веток, онлайн реп.
Есть подводный - в истории не стоит кликать на строчку, где было изменение больших бинарей - редактор зависнет надолго считая диффы... Надо будет им ишью завести чтобы был таймаут.
Пример - поговорил с одним NPC, он дал квест, после этого в другой локации появился другой NPC с которым надо тоже поговорить.
Первая мысль была примерно такая - иметь реестр квестов, диалогов и NPC.
В реестре NPC записи о том в какой он локации, в каком месте и какой у него сейчас диалог.
В реестре диалогов иметь записи о том какой квест активируется после этого диалога, куда перемещается NPC и какой у него будет следующий диалог
При загрузке локации проверять эти реестры и расставлять NPC согласно записям.
Довольно сложно получается. Есть какие-то способы сделать проще, может я что-то не вижу?
> Есть какие-то способы сделать проще, может я что-то не вижу?
Этапы квестов. Классика эрпогэ, существующая с хуй знает каких лет. Вкратце суть токова.
1. Реестр у тебя один, и называется он - база данных.
2. И в твоей базе данных лежат все квесты всех локаций.
3. И у каждого квеста есть поле "ЭТАП" целого типа, которое по умолчанию = 0
4. И у тебя есть сейвфайл, который организован (любым удобным тебе способом) как модификация основной базы данных. Загрузка сейва - это выполнение модифицирующего скрипта в БД.
5. И в процессе выполнения квеста у него увеличивается значение поля ЭТАП, то есть, меняется по сути этап квеста.
6. И увеличиваться он может не только на 1, а сразу на любое нужное тебе целое число, тем самым пропуская этапы. Так ты реализуешь ветвление событий.
7. А в диалогах у НПЦ у тебя будут закодированы условия появления ветвей диалога в зависимости от существующего этапа квеста. Если этап > 4 но < 7 то показать вот ту ветку.
8. И при загрузке локаций ты сможешь чекать этапы квестов и выполнять нужные действия, расставлять фурнитуру и НПЦ. Вплоть до того, что в менеджере загрузки локаций, ты сможешь чекать этапы связанных квестов и выбирать, какую из версий локации грузить в данный момент. День, ночь, война, пожар, руины, прошлое, будущее, иное измерение, и всё что пожелаешь.
> Довольно сложно получается.
А кто-то обещал, что будет легко? Эрпогэ - вершина геймдева. А Геймдев - вершина айти. Самая простая игра сложнее самого навороченного КРУДа. Самая простая эрпогэ сложнее самых навороченных кликеров.
Мне удивительно видеть, как люди без опыта в айти лезут в геймдев.
Я пока глубоко систему квестов не продумывал. Но имхо это иерархический конечный автомат. Обычно вырожденный, потому что квесты обычно простые - 1. выйди за забор 2. убей 5 волков. Рестарты и повторяемые для простоты не рассматриваем. Иерархический - потому что сами квесты объединены в цепочки. После выполнения квеста 1 можно брать квест 2. Да, там могут быть графы посложнее. Например если взял квест за красных, за синих уже не можешь.
Может быть, можно обойтись событиями. Например, когда ты завершил квест, посылается событие, и оно спавнит следующего непися. Сами неписи, в таком случае, мне кажется, являются тупыми объектами наподобие кнопок. Да у них есть примитивные состояния, типа позиции на карте, которые могут быть связаны с системой сохранения. Но сами они не отслеживают состояние квеста. Пример - в какой нибудь ММО непись стоит в одном месте, но в разговоре с каждым игроком он говорит с ним лично на основе состояния игрока. Один еще только берет квест, другой уже сдает. (Опять же пропустим сложные случаи, когда непись перемещается между фазами квеста или игрок присоединился посередине рейда - это все можно продумать).
В общем, имхо, ничего особо сложного, инкапсуляция, каждый делает свою маленькую часть работы и все.
То есть вот это я бы изменил:
>В реестре NPC записи о том в какой он локации, в каком месте
Ок
>и какой у него сейчас диалог.
Это перенес бы в состояние квеста у игрока.
Вообще мне нравится идея с графом состояний. Похоже на вот эту >>876566 систему с этапами
Есть начальный узел - это начало игры, и несколько конченых, по одному на каждый квест.
Между ними - множество узлов событий, они по умолчанию неактивны.
И есть несколько указателей, каждый указатель движется от начала к концам по узлам событий.
Узлы по умолчанию неактивны, разблокируются по событиям. Допустим ты нашел нужный предмет, инвентарь сообщает что предмет найден и следующий узел открывается. Или в конце диалога открывается следующий узел.
Узлы имеют типы - например:
- позиция NPC, при прохождени этого узла NPC перемещается в нужную локацию
- диалог NPC - это узел устанавливает NPC нужный диалог.
- квестовый узел добавляет или убирает в журнал квестов запись
тут много чего можно придумать.
Мне кажется с такой системой можно делать РПГ масштаба скайрима.
Это вопрос исключительно субьективного удобства. Что нравится, тем и пользуйся. Для остального есть тред движкосрача.
>>876642
> идея с графом состояний
> множество узлов событий
> несколько указателей
> Узлы по умолчанию неактивны, разблокируются по событиям.
Братан, братишка, браток. Как ты ни накручивай слои абстракций, в итоге у тебя на диске будет лежать плоский список, в котором всё будет сведено к индексированным записям. Так нахуя тогда накручивать слои абстракций? Ты только запутаешься в них. Система этапов не просто так является бессмертной классикой, потому что лучше нее ничего не придумаешь, и всё что ты можешь придумать, в конечном итоге сведётся к системе этапов. Все твои вот эти графы состояний превратятся в ту же самую таблицу. Но при этом, при саппорте этой системы, тебе придется переводить плоские данные в графы с узлами и переходами, а потом снова графы с узлами и переходами переводить в плоские данные. Впрочем, похуй же как делать, главное, чтобы тебе было удобно. Именно поэтому я не люблю аддоны и ассеты. Они сделаны так, что их авторам они удобны. Но это не гарантия что это удобно мне.
>Как ты ни накручивай слои абстракций, в итоге у тебя на диске будет лежать плоский список, в котором всё будет сведено к индексированным записям. Так нахуя тогда накручивать слои абстракций?
Потому что человеку удобнее работать с абстракциями, а не непойми каким плоским списком. Вот пусть на диске хоть ассемблер лежит, пишем то мы не на нем.
Простой пример - ты захотел вставить в первый квест дополнительную задачу. В случае графа, ты просто добавил и оно само пересчитается. В случае своего плоского списка, ты или сдвинул все последующие числа, сломав старые сейвы, или начал добавлять в конец, в результате у тебя уже не плоский список, а 1, 2, 1488. 3, 4. Что в итоге приведет к костылям, если ты где то проверял if quest < 5
Без понятия, бро, я не пользуюсь другими движками. Ты бы еще спросил, почему я с линукса на винду возвращаться на собираюсь, или почему пользуюсь блендером.
Резонное возражение. Я и сам к этому пришёл, когда дописывал пост. Именно поэтому я в итоге и написал:
>>876673
> Впрочем, похуй же как делать, главное, чтобы тебе было удобно.
> Я могу сделать часть интерфейса в 70% от высоты экрана?
Да.
> Есть какие-то гайды (на 4.1 или те, что не устарели)?
Я немного знаком с вёрсткой хтмл и легко пилил адаптивные в трёшке, поскольку оно там сделано по образу и подобию хтмл. Сейчас в четверке не касался этого вопроса. Но процентное соотношение там есть точно.
Там все довольно просто
Пик 1 - корневой контрол Full Rect занимает весь экран
Пик 2 - контрол с custom anchor, как раз и означает в процентах - 0 это край, 1 это дргой край, 0.2 это 20 процентов и тд
Пик 3 - контрол с custom anchor и anchor offsets, то есть когда относительно процентов еще и margin в пикселях
Пик 4 - это уже с контейнерами, контейнер сам расположен на 10 процентах, и растягивает контрол в него под это.
Кроме этого есть всякие контейнеры в которые уже по какой то логике набиваются дети, например grid container, horizontal box, vertical box, их можно вкладывать друг в друга, сейчас вроде бы есть и flow
Контейнер управляет лейаутом детей, но дети могут указывать как они хотят размещаться в контейнере, полями container sizing; fill или shrink, а также галочкой expand. В таком случае параметр Stretch будет уже задавать пропорции между такими элементами. На пик 2 - пропорции 3-2-1.
>>876770
Посетители треда выражают огромную благодарность!
Держи няшу.
>>876773
Не за что. Нюансов все равно много остается, я всех комбинаций не знаю, но база простая. Еще какие то настройки бывают не в настройках контейнеров, а в настройках темы, например отступ между элементами контейнера. Вот их похоже в процентах не задать. Но наверное можно из скрипта как то получить общий размер контейнера и высчитать. Будем считать это продвинутой темой.
Тут я забыл написать текстом, что есть margin container он используется чисто для отступа в дереве контролов, то есть даже если у ваших контролов нет возможности явно задать отступ, можно всегда обрамить это в margin.
На просторах гитхаба замечен такой проект Godot-Dodo
https://github.com/minosvasilias/godot-dodo
Процесс обучения описан так: с гитхаба спарсены проекты под MIT лицензией, потом чатугпт 3.5 турбо задавался вопрос что делает каждая функция.
В репе есть ссылка на веса, как я понимаю, надо их скачать, установить пререквезиты для питона и запустить eval.py В нем уже содержаться подобные тестовые запросы
'Listen to WASD user input and move current node accordingly.',
'Apply a new metallic spatial material with a red albedo color.',
'Create a raycast and cast from active camera to current node. Return ray collisions.'
В описании сказано что модель дожна лучше писать на гдскрипте, но хуже понимает более высокоуровневые запросы
Тестите, я сам с картофелины.
>с гитхаба спарсены проекты годот 4.0 под MIT лицензией
Забыл важное уточнение.
> я сам с картофелины
Эх, да и я тоже с утюга.
Ну чо годаны, роллинг релиз? Теперь живем на дев сборочках?
Я предпочитаю LTS. Впрочем... Все равно нихуя не делаю, так что можно и попробовать.
Имеется аниматед_сприте, все кадры анимации берутся из одной картинки. Или не аниматед, а просто спрайт с одной картинкой. Итоговый результат должен одинаково себя вести и с тем, и с другим.
Имеется канваситем-шейдер. Суть в трёх строках:
vec4 color = texture(TEXTURE, UV)
vec4 new_color = texture(my_uniform_sampler2D, UV)
COLOR = vec4(new_color.rgb, color.a)
То есть, простейшая штука. Скормить шейдеру текстуру и заменять на неё всё, что не прозрачное.
Но собака порылась в деталях. А именно - в анимации. Точнее, в атласах, как я понял. Для шейдера разные кадры анимации - это разные места на одной текстуре. С разным UV, соответственно. И из этого вытекают две проблемы:
1. Наложенная текстура растягивается на весь атлас, а не на выбранный кадр.
2. При проигрывании анимации анимируется и наложенная текстура.
Да, я могу подогнать шейдер под конкретный спрайт. Но у меня тут ареа должна автоматически вешать свой материал на любого кинематика или ригида, который в неё зайдёт, так что надо найти какое-то общее решение. Можно как-то скормить шейдеру то, что фактически отрисовывается, а не исходную картинку? Или ещё какие варианты решения есть?
Сегодня бегаю весь день, так что сам попробовать и показать не смогу.
Вариант 1 - nine patch rect. Там фишка в том, что рисуешь одну кнопку со скругленными углами, но растягиваешь ее рамку на нужное расстояние, углы при этом не масштабируя. Это контрол, со всеми вытекающими, но можно и для игровых объектов приспособить
Вариант 2. Пишут что есть ресурс StyleBoxFlat и у него Corner Raduys. не пробовал.
https://godotengine.org/qa/132106/how-to-create-rounded-ui-elements
Не исключаю что у тебя проблема в чем то другом, типа панель не использует какие то настройки темы. Тогда надо придумывать что то свое. Например использовать ту же кнопку только ненажимаемую для визуала панели. Годот - игровой движок, то есть в первую очередь это когда всякие спрайтики бегают и стреляют, а не инструмент иллюстратора в котором скопировано все что только бывает в хтмл.
Самое прямолинейное решение - UV надо умножать (или делить) на количество строк и колонок в атласе. Для этого можно завести uniform переменные в шейдере и выставлять их напимер из гдскрипта, взяв данные о твоем анимспрайте. Почитай тут например.
https://www.reddit.com/r/godot/comments/w3rhzy/shaders_for_animated_sprites_using_spritesheets/
Еще запасные идеи
Вариант 3. Рисовать SVG
Вариант 4. Шейдер рисующий любые линии, скругления.
Но я не знаю количество строк и колонок в атласе. Я вешаю шейдер на рандомный спрайт, у которого даже своего скрипта нет.
Может, можно было бы в скрипте-вешалке прописать, чтобы он выковыривал эти данные из АниматедСприте. Но я не нашёл в доках способа сделать это. Можно вытащить текстуру конкретного кадра, делать это по сигналу frame_changed.
Ов щи, пока писал, придумал. Можно узнать размер текстуры кадра, скормить его шейдеру; а шейдер знает размер текстуры атласа. Костыльно, но должно сработать. Не поможет, если анимация будет использовать более одно атласа, но у меня таких нет и, видимо, теперь уже не будет.
Ты прав, я перепутал с просто спрайтом, которого есть vframes и hframes. Уже не помню почему, отговаривали исползовать AnimatedSprite, в пользу AnimationPlayer.
Что касается AnimatedSprite, сейчас проверил, он возвращает SpriteFrames, у которого есть AtlasTexture, у которого можно получить region указанного кадра указанной анимации.
Думаю этого достаточно чтобы составлять автоматически каталог для всех спрайтов в твоей игре.
>SpriteFrames, у которого есть AtlasTexture
О, не знал, потому что в доках написано:
>Texture get_frame ( String anim, int idx ) const
И прежде я уже юзал эту функцию, чтобы автоматически отрисовывать персонажа в инвентаре, и не догадывался, что там атлас.
Нушош, тогда вопрос решён.
Там, наверное, не всегда атлас, есть же другой режим когда просто картинки накидываешь по одной. Но это тоже можно проверять.
> Уже не помню почему, отговаривали исползовать AnimatedSprite
Я напомню.
АниматедСпрайт нужен для одноразовых задач, например, сделать крутящуюся иконку сохранения, включать и выключать ей видимость, когда надо. Если нужно комплексно работать с анимациями, для этого создан универсальный АнимаПлеер, который хоть 2дспрайтами жонглирует, хоть 3дмешами, и состыкуется с универсальным АнимаТрии для создания стейтмашин.
Но на практике никто не мешает, конечно же юзать и АнимаСпрайт.
Анимаспрайт удобен для пикселярта, когда все анимации исключительно спрайтовые и нет никаких плавных переходов. И его очень удобно совмещать с анимаплеером и анимадеревом. Хотя, в общем-то, никто не запрещает вместо переключения кадров юзать регион в обычном спрайте.
https://www.youtube.com/watch?v=G8upcX3MrR8
1. Простые сеттеры свойств, в них по две строчки: задание свойства-переменной и вызов редрав_май_обжект()
2. Функ _реади() и в нём вызов редрав_май_обжект()
3. Ну и собсно редрав_май_обжект(), который собирает вместе все нужные параметры и задаёт свойства детям.
Я вот думаю. Целесообразнее ли вместо этого заюзать виртуальный метод _draw() ? Или он вызывается каждый кадр, так что пихать туда гдскрипт плохая идея? Или есть общепринятый какой-то другой метод, которого я не знаю?
Не очень понял твою терминологию. Дочерними/детьми и родительскими называют положение в дереве нод, а дальше ты говоришь про виртуальный метод. Может ты имел в виду наследованные и базовые?
Когда вызывается метод draw написано в документации.
Updating¶
The _draw() function is only called once, and then the draw commands are cached and remembered, so further calls are unnecessary.
If re-drawing is required because a state or something else changed, call CanvasItem.queue_redraw() in that same node and a new _draw() call will happen.
Стоит ли привязывать к нему логику - не уверен. Все таки мне кажется ты описываешь больше логику, а не отрисовку. Под отрисовкой там имеется в виду нарисовать линию, кружочек.
Cruelty squad, еще какой-то забагованный ремейк Соника, хотя они все такие независимо от движка. Вообще такой вопрос сейчас не особо актуален, в 4.0 3D абсолютно другое, но естественно с момента релиза еще не прошло достаточно времени, чтобы на нем успели сделать что-то крутое.
>или хотя-бы играбельная) 3D игра
>С графикой лучше чем абстрактные кубики
Естественно, та же Human Diaspora, но разраб психанул от неуспеха и удалил все видосы с ней с реддита и ютуба, а мне лень искать их на компе сохраненку.
А вообще то любой может скачать разные демки и оценить возможности рендера
https://github.com/perfoon/Abandoned-Spaceship-Godot-Demo
https://github.com/mikatomik/Godot-4-Overgrown-Subway-Demo
https://github.com/gdquest-demos/godot-4-3d-third-person-controller
Это демки на 4-ке
>а поддержка 3д это так для галочки?
Всегда нормальная поддержка была. Вот типичная игра с какого то мелкого джема.
>какой-то забагованный ремейк Соника
Не забагованый. Там специально стримеры по 100 раз дрочили сейв пока память не утекала. У нормальных игроков в тот же день уже летсплеи целиком игры без пробелем были.
https://www.youtube.com/watch?v=s9AO18j1cyE
>Дочерними/детьми и родительскими называют положение в дереве нод
Ну да, про это и речь.
Сейчас в родителе три функции, которые так или иначе влияют на отрисовку детей. А я спрашиваю, не лучше ли все их запихнуть в один _драв().
>Когда вызывается метод draw написано в документации
Хз, где это написано, вот тут такого нет:
https://docs.godotengine.org/en/3.5/classes/class_canvasitem.html#class-canvasitem-method-draw
>Все таки мне кажется ты описываешь больше логику, а не отрисовку.
Исключительно отрисовку.
Но если _драв() всё равно надо вызывать вручную, то лучше оставлю как есть.
Демки не в счёт таккак это фактически реклама. То есть вопрос должен звучать так: Действительно ли можно использовать движок для создания жизнеспособной игры с не нулевой графикой, или он годится только для демок и прототипов которым ясно дело такая производительность не требуется
>То есть вопрос должен звучать так: Действительно ли можно использовать движок для создания жизнеспособной игры с не нулевой графикой,
Странная переформулировка, ну на этот вопрос ответ да.
> такая производительность
Это какая еще такая? Производительность в основном зависит от постпроцессинга (врубаю всякие шейдеры и падает с 120 до 60, да и вообще некоторые эффекты требуют второго вьюпорта с дублированием прорисовки), от очень больших текстур (запускал на некроПК,накидав много ассетов с 4к текстурами - вот тогда начинаются затыки, потому что приходится из памяти в видляху постоянно свопать - поменял на 512 и все летает), к тому же имеет смысл объединять текстуры в тримшиты. В третьих все эти динамические освещения - GI, voxel, Reflection probes, объемный туман и так далее.
И как можно заметить, все эти три пункта надо выносить в настройки, тогда внезапно на слабом компе можно понизить качество картинки и производительность вырастет, кто бы мог подумать.
Еще проблема может быть если пытаться тупо столкнуть кучу физических объектов (если например делать всех неписей физическими телами и они окажутся во взаимодейтсвии через какой нибудь Area все со всеми). Это решается тем что они должны ходить упрощенными методами - например навигацией, которая еще и пересчитывается не каждый кадр.
>Демки не в счёт таккак это фактически реклама
Демки, блджад, это демки. Они нужны для того чтобы проверить как что работает из коробки и что можно поменять и сколько всего потянет твой комп.
Делаю генератор карт (https://www.redblobgames.com/x/2022-voronoi-maps-tutorial/) и к генератору пишу некоторое подобие эмулятора цивилизаций (https://drtardigrade.itch.io/worldhistorysim):
https://gitlab.com/liaten/godot_map_course_work
Скрины приложил
По ссылкам не ходил, по скринам что-то типа Азгаара-мап-генератора?
Про азгаар знаю, хороший генератор, оттуда тоже беру некоторые фичи
Я немного предвзято распишу. 4-кой же можно начинать пользоваться, но она сыровата у нее есть несколько минусов.
1. 3д экспорт в веб в ранней разработке, нет теней, нет многих спецэффектов.
2. вулкан же не везде работает нормально. Так что для разработки на 4-ке уже нужен комп помощнее. Даже банальный запуск редактора и игры в 3-ке GLES2 ощутимо быстрее, чем в 4-ке OpenGL.
3. 3д террейна пока не запилили, и уже месяц даже обсуждений не слышно
4. Если делать 2д игру, то андроид и веб билды будут тяжелее, дольше грузиться
5. Туториалы пока будут попадаться на 3-ку больше, поэтому новичку придется разбираться как что поменять на лету.
6. Аддонов пока меньше, хотя ситуация уже выравнивается, к тому же в основном на 3-ку аддоны заморожены и не будут появляться новые или дорабатываться.
7. Редактор сыроват, в 3-ке как то получше редактируется код, в 4-ке постоянно какие то затупы с автодополнением. Иногда может упасть от неудачного клика по ноде. (Понятно что любой софт может, даже майкрософтовский, но по ощущениям в 4-ке это происходит чаще. несколько раз в день)
Так что я бы сказал так
Если хочешь вкатываться на будущее, с долгостроем, с А-АА игрой, с мощными спецэффектами, бери 4 ку. За год ее уже доведут до приемлимого состояния.
Если хочешь просто потыкаться в 2д на компе, тоже можешь взять 4-ку.
Если хочется супер мега оптимизированную игру которая будет и в вебе и на мобилках, тут я бы в ближайший год все еще 3-ку использовать буду.
Согласен с этим аноном, беру свои слова назад с советом 4-ки для начинающих. Она подходит для тех, кто уже знает как работать с годотом, но только начинает проект.
Спасибо. не слышал про такой.
Автору надо бы его в ассетлиб закинуть, да и теги на гитхабе проставить - я бы про него и не узнал, не смотрю ютупчик.
В ассетах такой мелькает постоянно в обновлениях, майнкрафтоподобный
https://godotengine.org/asset-library/asset/1650
> Где тысячи бесплатных моделек?
В параллельной вселенной победившего коммунизма, где людей кормят бесплатно.
Кроме самой юнити, в которой она бесплатна только пока с тебя взять нечего.
Если до этого пользовался Юнити, то меньше недели. Если не пользовался, то две недели максимум.
Уточнение - zylann таки портировал свой height map на 4-ку. Попробовал, текстуры работают, редактирование мышкой работает, коллайдер работает. Не сработала рандомная генерация в меню. Теоретически можно редактировать в 3ке и перекидывать в 4ку. Завтра более плотно потестирую, разные ситуации, экспорт может быть, терраформинг из скрипта.
Качается ветка godot4 с гитхаба
git clone -b godot4 https://github.com/Zylann/godot_heightmap_plugin
>>878950
А куллинг он починил?
Объясню. Когда я пользовался его плагином пару лет назад, там был баг куллинга, из за того что меш по факту под ногами, а отрисовка происходит дисплейсом в шейдере, то когда поднимаешь взгляд вверх, срабатывает искаробочный опенгл фруструм куллинг и все горы террейна тупо исчезают, потому что из области камеры ушла изначальная поверхность. Так вот, починил он это?
Надо проверить, по твоему описанию это похоже на баг движка, чем на аддона, поискал такие ишью, вроде бы закрыты. Аддон генерит AABB и сообщает движку. По хорошему надо проверить везде, в 3, в 4 Forward+, Mobile и Opengl. Если что-то не работает - из нагугленного надо проверить как работает scale или map scale террейна (наверное в идеале надо оставить 1:1)
И еще написано что у GeometryInstance есть такое свойство как extra cull margin, то есть в теории можно любому объекту подкрутить, чтобы он был виден дальше чем надо (это часто нужно частицам). но вот тут я не уверен есть ли такая опция в террейне, но на первый взгляд ее нетрудно прикрутить, ведь террейн предположительно виден всегда.
Звучит обнадёживающе. Проверь пожалуйста. Я не могу, у меня лапки.
Как в такие списки попасть?
В ютубе искаропки автогенерируемые и автопереводимые субтитры. Это без учёта того, что субтитры могут быть вручную добавлены автором видоса, и на нескольких языках. Да, надмозг иногда тупит, но в целом понять можно о чём речь.
Ну а если писать письма туда на емейл, тупо открываеш в соседней вкладке переводчик, и тупо переводишь, и тупо копипастиш.
> Это без учёта того, что
И это не говоря о яндекс-браузере, в котором сделали нейросетевую озвучку.
Каким методом пробрасываются переменные из одной сцены в другую?
Есть несколько вариантов
Вариант 1, сигналы. ui подписывается на сигналы, вместо переменных здоровья делаешь сеттер, в нем сигнал отправляется.
Вариант 2. Тупо жесткая связь. Буквально если они в дереве рядом, то "../scene".health. Минусы понятны, что это сложно изменять. Но для джемов вполне норм.
Вариант 3. Менеджер. Похоже на вариант 2, только связь чуть послабее, потому что ты обращаешься к конкретному менеджеру, а он уже достает из нужной ноды.
Вариант 4. Объединить сцены. Отчасти похоже на вариант 2. Это, например, если говорить о полосках над персонажем. То у тебя может быть спрайт, а сцену с ui добавить ему дочерней.
https://www.youtube.com/watch?v=M8-JVjtJlIQ
> ui подписывается на сигналы, вместо переменных здоровья делаешь сеттер, в нем сигнал отправляется
Чтобы подписаться на сигнал, нужно знать ноду. А это связь. Таким образом пункты 1 и 3 по сути равнозначны, в случае если ты юзаешь шину сигналов (тот же менеджер) и пункты 1 и 2 равнозначны, если ЮИ знает о ноде и подключается к её сигналу напрямую.
Далее. Варианты 2 и 4 приведут к производственному аду, даже на ТВГ, тупо в первую неделю так нахуевертишь, что ко второй неделе голова бомбанёт и с конкурса сольёшься. Проверено.
Поэтому остаётся только пункт 3, только вместо менеджера - шина сигналов (event bus (design pattern) (for googling) только такой вариант я подвачую.
Двачую шину. Когда я узнал, что в Годоте можно вызывать сигналы другой ноды через код и об этом паттерне в частности, то у меня практически полностью исчезли проблемы, связанные с коммуникацией различных сцен между собой.
Все же поправлю тебя немного.
Чтобы подписаться на сигнал надо знать ноду, но связь не возникает. Связь будет существовать уже только в виде сигнала. Саму подписку сможет оформить фабрика, например из массивчика. А она сможет прицеплять ноды как угодно, поэтому не будет жесткой связи вида "../"
Поэтому варианты 1 и 3 НЕ равнозначны. В 1 фабрика знает о ноде и о ui, и только при создании. Нода и ui ничего не знают о фабрике (в отличии от менеджера в 3, о положении которого они обязаны знать чтобы общаться) и не знают о взаимном расположении друг друга, только о сигналах.
>>879222
Вариант 4 и так постоянно используется со штатными нодами годота. Например у KinematicBody обязаны быть дочерние CollisionShape, и не редкость когда родительский скрипт ими управляет. Например когда персонаж приседает и надо уменьшить его рост. Движение вверх тоже встречается, у того же персонажа может быть дочерний детектор попаданий пуль, который сообщает родителю о попадании напрямую. Так что никакого производственного ада нет, если это ближайшие соседи. Производственный ад на джемах возникает только от спешки и попытки что то начать переставлять, просто этого делать не надо и надо доделывать уже так как начал.
> надо знать ноду, но связь не возникает
Там у Хуана какая-то чорная магия, как минимум в трёшке была, что если дёрнуть сигнал на выгруженной ссылке, то просто ничего не происходит, ну и в консольку печатается еэкзепшн (хотя почему чорная магия, дописал предложение и сам понял, что экзепшн обрабатывается, раз в консольку пишется). В других движках аналогичное действие приводит к крашу.
Есть. Почитай гайды. обычно проблема в том, что колесо надо размещать там где оно будет при сжатой рессоре, и уже потом вытолкнуто пружной, а не в конечной точке. То есть в твоем случае возможно его просто выдавливает туда или оно вообще спавнится под землей. Можешь попробовать спавнить машину в воздухе для проверки. Второй момент что колеса вообще не сильно надежны и могут при сильном воздействии провалиться, ну то есть если большая масса, сила пружины или с трамплина прилетел. Я когда авиасим пилил так и не справился с колесами, сделал свой костыль. Честно говоря даже в доках сказано что скорее всего понадобиться делать свое.
Алсо можешь скачать ассет и посмотреть как в них сделано
3. https://godotengine.org/asset-library/asset/661
https://github.com/BastiaanOlij/vehicle-demo
4. https://godotengine.org/asset-library/asset/1879
Еще машинки были в двух мультиплеер туторах, правда мне влом сейчас их искать.
>в том, что колесо надо размещать там где оно будет при сжатой рессоре
странный подход
>Можешь попробовать спавнить машину в воздухе для проверки
Она и так спавнится выше
>Честно говоря даже в доках сказано что скорее всего понадобиться делать свое.
Читал, мне кажется я не осилю в плане алгебры векторов (я вообще нубасик), но могу попробовать
>Я когда авиасим пилил так и не справился с колесами
Я думал что дело в фпс симуляции (не успевает просчитать между тиками), но добавление фпс проблему не решило.
>Алсо можешь скачать ассет и посмотреть как в них сделано
Да качал уже, чего-то особенного не подметил. Думаю тоже на настройки подвески т.к. от нее реально что-то меняется, но это странно, что нужно искать какие-то настройки чтобы шины не проваливались. Если бы у них был нормальный collision shape то такого бы не было.
ты себе не представляешь, СКОЛЬКО настроек надо искать когда делаешь технику. Не меньше 10.
> мне кажется я не осилю в плане алгебры векторов
Мне тоже так казалось, три года назад, а щас ничего, без подсказок гугда трансформы вращаю.
Абсолютный новичок в этих ваших Годо, сижу весь день и не понимаю как это должно работать.
Цель: при нажатии соответствующей клавиши, одна из панелей инвентаря (Заданного через GridContainer) должна поменять свою текстуру.
Для пояснения - в одном положении это соответствует активной правой руке, во втором левой.
Перекопал с десяток примеров/обсуждений/глянул документацию, так нихрена и не понял как это (Изменение текстуры в stylebox) правильно делается.
Хуйня твои объяснения, заскринь структуру сцены, саму сцену, и по скрину объясни, чё хочешь сделать
Стили - они для другого. Их задача - обеспечить единообразие вида всех элементов интерфейса. Если тебе надо задать из кода произольную текстуру, то используй TextureRect, там тупо меняешь свойство texture и всё. Ещё посмотри в сторону TextureButton, возможно, это тебе больше подойдёт (я не оч понял, что ты хочешь сделать); к ней можно без кода прикрутить шорткат.
var new_panel_stylebox = self.get_stylebox('panel').duplicate()
new_panel_stylebox.bg_color = new_color
self.add_stylebox_override('panel', new_panel_stylebox)
Скачал пример от 3 версии, он не работает на 4, хотя я его ручками подправил. Посмотрел там скрипт: он просто включает мотор и крутит его.
Вроде бы все настроил, но при нажатии на кнопку колесо чуток проворачивается вперед и все, хотя я там уже 9999 велосити накрутил, ничего это не меняет.
если крутить напрямую rigidbody3d через angular velocity (wheel_back.angular_velocity.z = 10) то крутит нормально
Это баг или там bullet где-то отдельно включается?
В чём суть. Хочу отрисовать текст красиво, чтобы он появлялся по буквам, причём каждый чётный символ перед буковками появлялось ещё "_". Количество показываемых символов - export(int) var shown_chars. Показываемый текст - export(String) var mytext.
Сначала добавляю подчёркивание:
>mytext.erase(shown_chars - 1, 1)
>mytest = mytext.insert(shown_chars - 1, "_")
А дальше первый вариант
>label1.text = mytext.left(shown_chars)
>label1.percent_visible = 1.0
или второй вариант:
>label2.text = mytext
>label2.percent_visible = float(shown_chars) / float(mytext.length())
Проблема в том, что в двух вариантах разный результат. Первый работает надёжнее, но есть проблемы с переносом слов: если слово не помещается на строке, оно перенесётся только тогда, когда наберёт достаточно букв. Собсно, percent_visible для этого и существует. Но во втором способе другая проблема: невозможно предугадать, какой символ будет последним. Там какая-то магия происходит в преобразовании интов во флоты.
Попробовал наоборот, сначала задавать процент,
>export(float, 0, 1) var shown_percent
а потом из него считать количество видимых символов:
>var shown_chars = int(shown_percent * float(leng))
Ну и снова, сначала добавляю подчёркивание (см. выше) первый вариант без изменений (тоже см. выше) или второй упрощённый:
>label2.text = mytext
>label2.percent_visible = snown_percent
Та же дребедень. Символ подчёркивания то вообще не отрисовывается (уходит за пределы видимого), то оказывается предпоследним и после него ещё один.
Как с этим совладать, я чёт пока так и не придумал. Годаны, выручайте. Хочу заюзать percent_visible, но не могу. Пока просто обрезаю текст.
В 4ке добавили какой то параметр который смотрит слова наперед чтобы переносы не скакали.
https://www.youtube.com/watch?v=7QvhCDsFkk0
Потому что ты не пил кофе давя питона.
На самом деле значит в уроках оно не требовалось.
Проверь gdscript keywords мб еще что интересного найдешь.
Потому что это хуйня и костыль, сраный атавизм. Как какое-нибудь GOTO. Только баги рождает, хотя всегда есть более эффективное решение.
Но вот тебе умное видео: https://www.youtube.com/watch?v=4xMaq-qVQGY
> Почему, блядь
Потому что инструмент надо изучать в первую очередь по официальным докам, прочитав хотя бы 1 раз целиком
https://docs.godotengine.org/en/3.6/tutorials/scripting/gdscript/gdscript_basics.html
>ни один пидорский соевый гомосатанинский гайд от GDQuest не рассказал мне про yield/await?
Вижу гайд GDQuest по yield 4 летней давности, так что вини только себя.
>ЧУТЬ ЛИ НЕ САМОЙ ВАЖНОЙ ФИЧЕ В МИРЕ
Если ты не знаешь о ней из опыта программирования, то скорее всего она тебе не нужна. Анон выше может и преувеличивает насчет устаревшей, но то что новичок может ее совать где угодно и получать баги это факт. Я сам поначалу в ready костылял по два yield(get tree(), "idle frame") "чтобы все наверняка загрузилось" и потом удивлялся с трудноуловимых багов.
>Я сам поначалу в ready костылял по два yield(get tree(), "idle frame") "чтобы все наверняка загрузилось" и потом удивлялся с трудноуловимых багов.
На что заменил?
Не сильно, но отличается.
Гайды на конверсию есть
Например вот выглядит вменяемым
https://gist.github.com/WolfgangSenff/168cb0cbd486c8c9cd507f232165b976
Если быстренько по нему пройтись, с чем ты скорее всего столкнешься
Сигналы
button.connect("pressed", self, "_on_button_pressed") --> button.pressed.connect(_on_button_pressed)
yield(get_tree(), "idle_frame") --> await get_tree().process_frame
Аннотации
onready, export, tool --> @onready, @export, @tool
Спавн
tscn.instance() --> tscn.instantiate()
Функции, ноды - большой список
deg2rad --> deg_to_rad
Spatial --> Node3D
change_scene() --> change_scene_to_file/change_scene_to_packed
Свойства
setget --> set(value):... get(): ...
Физика персонажей
KinematicBody --> CharacterBody2D/3D
теперь используется встроенное поле velocity,
Т.е. не надо будет вmove_and_slide передавать переменную,
а надо прямо менять саму velocity.
Шейдеры
Надо в начале самому объявить SCREEN_TEXTURE для постобработки
hint_color --> source_color и прочие переименования
Объекты
if object: --> if object == null:
>>879847
Во-первых, дяденька, я программист ненастоящий, я годот на стройке нашел. Во-вторых, я вижу эту хуйню и не представляю, как в принципе писать пошаговую игру без нее. Я вот в ужасе представлял, какой огород мне придется городить, чтобы ждать завершения вражеских анимаций в их ход, а тут оказывается, что я могу тупо во вражеский ход пройтись по всем врагам циклом.
> я вижу эту хуйню и не представляю, как в принципе писать пошаговую игру без нее
Стейтмашиной.
И ваще. В любой непонятной ситуации создавай стейтмашину.
Ну вот например, курсы по юнити (для сравнения) начинаются с объяснения что такое стейтмашина и как она важна в геймдеве. Такшта думой сам, как относятся.
>>879861
Я имею ввиду, там можно было и без корутины обойтись, добавив ноду таймер, сделав ей ваншот и в этой функции писать if !timer.enabled: timer.start(2.0) и потом ещё одну функцию приконнектить к таймеру, которая будет делать exit(), но для объяснения сути в рамках туториала проще влепить yield()
Стейт машина это что то вроде состояний и переходов changeStateTo()
1. ожидание ввода игрока -> 2. ход игрока -> 3. ход противника -> если еще есть противники, то 3 иначе 1
В общем yield тут не обязателен, changeState может вызывать подписанный на сигнал обработчик.
Если что в коде со скришота angular upper И lower limit просто тестовые, должны быть (как я понимаю) 180 и -180 (полный оборот) крутится в настройках на правой панели.
честно говоря судя по этому https://github.com/godotengine/godot/issues/66335 еще не имплементед в 4-ке, хотя там есть ссылка на довольно свежий бранч где уже добавлены моторы, но нет пружин все равно нет.
4.0.3?
И там версия с сирашпом есть и без него. Чем отличаются? Насколько вообще сишарп там норм? Или лучше их языком пользоваться?
Хочу с 2д побаловаться
>Какую версию качать-то?
Тред полистай >>877791
>>880059
> Насколько вообще сишарп там норм?
сишарп как сишарп. Им мало кто пользуется, так уж сложилось, новичкам все покрывает gdscript, олдам gdscript+cpp. Но если знаком, можешь и на нем писать.
>>880062
Постоянно фиксят, на сайте же написано что сейчас бета 3.6
>>880063
3д модели как таковые технически можно, из стора хз, надо во первых смотреть лицензию позволяют ли там использовать модель вне юнити, во вторых может быть какие то особые форматы. Так то я и из анрила вытаскивал.
>>880069
о что сейчас бета 3.6
Ну просто они 4 выкатили же.
А скачать с офсайта можно 3.5 только либо 4.1.
3.6 будет LTS версией то есть поддержка как минимум год-два. 4-ка догонит по фичам/состоянию только в 4.2-4.3.
Скачать беты можно из новостей, там ссылки на репозиторий со всеми версиями.
> Какую версию качать-то?
Открываешь повершелл, если ты на венде, а если не на венде, а на линуксе, то зачем качать? Юзай пакетный менеджер своего линукса.
Эм, так вот, на венде открываешь повершелл и пишешь:
>Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
>irm get.scoop.sh | iex
Закрываешь повершелл и открываешь заново. Пишешь
>scoop install 7zip
>scoop install git
>scoop bucket add extras
>scoop install godot
Идешь в пуск -> scoop apps -> godot
Открывается свежий стабильный релиз.
Автоматически не обновится, пока не напишешь в помершеле
> scoop update godot
Такшта можешь смело девелопить, не боясь, что внезапным обновлением похерится проект.
Ага, карп в пакете.
Из серии, прототип делается за день, а потом нерешаемые годами проблемы.
1. Видео. Годот не играет Mp4, потому что патент на H.264 до 2028 года. Значит надо мутить что то с встраиванием плеера, ffmpeg или mpv. Там без пересборки движка не обойтись, потому что надо встраивать окно внутрь opengl как то. Кроссплатформенность тоже под вопросом. Смотрел как другие делают, в Kurobe просто андроидный видеоплеер видимо, или хочешь сам ебись с libmpv.so. Собственно поэтому всякие ffmpeg или mpv распространяются в исходниках, хочешь собрать для себя - все легально, а бинарники распространяют только через какие нибудь балканские сервера где не прилетит DMCA.
С юутубом тоже непонятно, или комбинировать с yt-dlp или п.2.
2. Браузер. Например для капчи. Сейчас капча картинкой, но ведь может вылезти окно Клаудфронта. Или на какой то борде будет гуглокапча. Посмотрел аддон CEF (Chromium embedded), работает, но весит 1 гигабайт, чтобы показать капчу, карл. Может быть это дебаг, особо не ковырялся пока. Еще есть WebView но подозреваю там те же проблемы со встраиванием будут.
3. Просто много мелочевки. Те же теги парсить, прочитал что админы могут в посте любой html писать. Например оформление в /ld веселое. Кэш для загрузки картинок. Переадресация на /arch-ив. Настройки ебойки.
https://github.com/godotengine/godot/issues/74123
Теперь ты понимаешь, что браузеры - вершина девелопинга, самый продвинутый и сложный софт на наших устройствах.
да он искусственно переусложнен, плюс пилился во многом некомпетентными вкатунами, плюс монолит вместо модульности и линуксвей. Та же гуглокапча - специальная подстава, я где то читал что там загружается скрипт виртуальной машины на JS, и начинает двигать невидимые квадратики и блоки, а поскольку стандарт там та еще ебанина, то вот кривой конечный результат должен совпать с эталоном на сервере.
В принципе сделать перечисленное не проблема, и плеер встроить и капчебраузер, только не приблизит меня к цели - а цель у меня была не капчевалка на годоте, а компактная, кроссплатформенная, легко и легально распространяемая капчевалка.
А сам рендер текста на годоте относительно просто делается, ну может со спойлерами повозиться придется подольше.
В общем пока писал, в очередной раз осознал, насколько прав и Мицгол со своим гипертекстовым фидонетом, и всякие линуксы распространяемые в сорцах. Ладно надо завязывать, пока templeOs2 не начал писать. А еще как вспомню про эту тяночку... https://habr.com/ru/companies/timeweb/articles/734652/
Хуйня типа хромиума явно максимально переусложнена, но она также хотя бы работает относительно нормально. Если скачать какую-нибудь хуйню на кастомном движке типа Epiphany, то можно охуеть с того, как 90% сайтов либо не грузится, либо просто крашит браузер. Если бы было просто сделать альтернативу, то они бы уже появились, а так есть только полудохлая мозилла.
Могу основным моментам научить. Потом будешь игру помогать мне делать :3
Пиши сюда: telescope#8606
angular_speed вроде как равен 3.14 радиан, т.е. 180 градусов.
А поворот на очень малый угол идет.
Да и вообще вопрос, почему эта функция запускается. Это же вроде просто ее определение (конструктор).
Или она и не запускается? А просто из-за того что вызывается поле класса (rotation) оно само считается? Ну и странно что поле класса встроенного класса никак не выделяется
А я понял, эта встроенная функция сама запускается каждый фрейм.
Это называется callback. Да, ты только определяешь функцию, но вызывает ее движок. В принципе большинство таких функций начинается с подчеркивания.
Тут тоже понял, там же на дельту умножается, а число меду фреймами наверное 0.000001 секунд
Есть функция которая возвращает значение (пик 1)
Есть функция которая использует предыдущую и сравнивает значения (пик 2)
Есть ошибка которая портит мне настроение (пик 3)
Есть значения которые первая функция возвращает (пик 4)
Почему там какой-то объект а не цифра единичка?
У тебя видимо туда вывалилось то что в yield(там же не итовое значение), а не return.
Не понял, зачем функция в которой и return и yield
Да ты прав. Попробовал запустить без yield и все пошло как надо.
Мне нужна была штука которая запаузит выполнение функции, типо wait(). В интернете сказали использовать такую конструкцию. А то что yield что-то возвращает мне даже в голову не пришло, лол
Спасибо за наводку
Вот к примеру как вообще пайплайн 3д игры делать если он не могет импортировать анимации на риг вообще, если скелет не женерик готовский
И это даже не в планах разрабов
Т.е. тут тупо каждую 3д модель надо сразу со всеми анимацими экспортировать, а если нужно добавить анимацю, то весь ассет с нуля переимпортировать
Ну хоть бесплатно
https://github.com/godotengine/godot/issues/71525
Победил данный косяк смешнейшим костылем - сразу вспомнил юность и модинг морровинда
>тут все супер плохо
То, что не так как ты привык в свовем первом движке != супер плохо. Это же не клон или копия. Блендер тоже не майя.
Но конечно ручной работы больше, с этим никто не спорит.
>>876327
> если скелет не женерик готовский
Это утверждение вообще непонятно какой смысл несет. В годоте нет встроенных ригов и никаких ограничений на них тоже нет. Иначе как бы анимировали волков, драконов?
>тупо каждую 3д модель надо сразу со всеми анимацими экспортировать, а если нужно добавить анимацю, то весь ассет с нуля переимпортировать
нет, это не так. Это всего лишь один из способов, самый прямолинейный, и в целом логичный и приемлимый - добавил новую пачку анимаций, импортировал, отредактировал animtree и скрипты стейт машин.
Но ничто не мешает тебе экспортировать новый gltf с только нужными новыми анимациями, импортировать их, и уже в самом годоте их перенести на первую модель. В 3-м это делается через save-load .anim файлов из аним плеера, в в 4-м там есть "библиотека анимаций" для подобного. И, кажется, уже и ретаргет для других скелетов запилили, сам не пробовал.
Я описывал воркфлоу который подходит под мои нужды. Это скетчфаб + блендер + миксамо+ годот, ну в идеале конечно еще каскадер и свои анимации.
>>880367
Косяк был в том, что при импорте новых анимаций на основной риг происходила их поломка - стартовые вращения были не правильными, костыль состоит в том, чтобы при импорте новых анимации в -1 кадр им ставить кадр с т-позой(нулевым кадром) тогда все вращения в импортируемой анимации корректы и после этого -1 кадр можно удалять
Возможно, я с таким и в других инструментах сталкивался, всегда возможна путаница между рест позой и т позой. Поэтому я стал все.в миксамо тоже от тпозы делать.
Алсо, в каком то скрипте импорта читал, что годот играет с 1 кадра, так что модет он попросту не считывал 0й. Но это уже неточно.
extends Node2D
var cell_size = 48
var cord = Vector2(0,0)
var gestures = []
func _input(event):
if Input.is_action_pressed("Clicker"):
var pos
pos = Vector2(int(get_global_mouse_position().x/cell_size),int(get_global_mouse_position().y/cell_size))
if pos != cord:
cord = pos
gestures.append(cord)
print(gestures)
Вопрос номер раз: вот у нас появляется после нажатия ПКМ первый элемент массива с координатой (x;y). Как мне вычесть из координат (1;1) координаты (x;y), а затем прибавить полученное значение (x1;y1) ко всем элементам (в том числе к первому)? Координаты (1;1) будут присвоены новой переменной Vector2, а все преобразованные значения будут внесены в новый массив.
Вопрос номер два: как мне поэлементно сравнивать два массива? Хочу, чтобы массив с преобразованными значениями на каждом этапе добавления этих значений сравнивался с некими шаблонами.
Вектора поддерживают математические операции (главное чтобы с обоих сторон от знака были одинаковые типы векторов).
>прибавить полученное значение (x1;y1) ко всем элементам (в том числе к первому)?
Если у тебя список векторов [1,2,3...n] то:
for i in range(len(твой массив)): # возможно вместо len, нужен size
твой_массив += полученное значение (x1;y1)
## возможно твой_массив = твой_массив + полученное значение (x1;y1)
возможно как-то так (не в курсах за gdscript, больше за python)
пройди курс python на stepik
Накатить? Мб накодить?
Накодить можно, но нужна инфа от гуру годота по: детализация объектов, область видимости (есть ли они из коробки)
ну т.е. должно быть дерево объектов которое при каждом шевелении камеры обрабатывается, есть оно в кадре или нет (нужно его рисовать или нет и с какой детализацией).
https://youtu.be/iadb1XyIq4c
В общем, эта уеба не хочет прибавлять к массиву вектор. Выдает "Invalid operands 'Array' and 'Vector2' in operator '+'."
extends Node2D
var cell_size = 48
var cord = Vector2(0,0)
var gestures = []
func _input(event):
if Input.is_action_pressed("Clicker"):
var pos
pos = Vector2(int(get_global_mouse_position().x/cell_size),int(get_global_mouse_position().y/cell_size))
if pos != cord:
cord = pos
gestures.append(cord)
var a = Vector2(1,1) - gestures[0]
for i in range(gestures.size()): gestures += a
print(a)
print(gestures)
else: gestures = []
Переменная а прибавляется только к первому элементу массива gesture. Все остальные элементы остаются без изменений. Что-то не так с циклом for?
Сделать - можно, но работы надо сделать много (пилю опенворлд мечты потихоньку)
Накатить в виде "закинул ассеты и оно само" - такого нет.
Есть ассет на 3/4 под названием zoneloading, но скорее всего придется делать свой на квадратные чанки. Умный куллинг (для ситуаций когда ты в городе и куча домов перекрывают друг друга) все еще под вопросом.
В годоте есть отладчик с брейкопинтами, возьми и пройдись им. Или печатай print.
Поскольку двач съедает форматирование, угадать что у тебя за код невозможно. Может быть у тебя массив всегда или с одним элементом, или стерт последней строчкой else.
Еще советую добавить в мастер файл анимацию RESET в которой т-поза и больше ничего. Это тоже может исправить какие-то проблемы. Анимация с таким именем выставляется при сохранении сцены.
Это может помочь если какая-то анимация, скажем idle, выставила не ту позу, и все анимации начинают играться от нее, немного перекошенные.
Кликнуть слева от номера строки, появится красная точка, в этой точке программа остановится, потом можно нажимать F9 и F10, чтобы выполнять по строчкам. (одна из них заходит внутрь функций).
>вот сам код
Ну моя гипотеза та же , input получает разные события, например движения мыши, во всех эти случаях код попадает в else и опустошает массив.
Попробуй делать print(even) в начале, например.
Отдельную сборку годота надо что ли?
И как он вообще, норм? Или ебаться надо будет?
Вроде читал что если шарп, то нельзя на андроид портировать?
Да, отдельная сборка в любом случае.
Да, вроде в 4.0 нет C# Android, iPhone и Web HTML.
В 3.х должно быть есть все, давно не проверял, можешь скачать export templates и посмотреть что там в папках.
а чо c# медленнее чем gdscript?
В плане? Я когда писал клеточные автоматы (типа "Жизнь") C# очевидно быстрее был в рассчетах.
Я не настолько ебанутый.
Высрал ее еще в твиттер. Выхлоп ожидаемо никакой.
> А то что yield что-то возвращает мне даже в голову не пришло, лол
Оно и не могло прийти. Синтаксис не подразумевает этого. Я сам подорвался на этой мине пару лет назад. Если в функции есть илд, то когда он срабатывает, функция возвращает специальный функшн-стейт вместо того, что она должна возвращать.
> bb коды съели скобки
Разрешите вздушнить?
Юзай пастебин или скриншотируй код.
> Я не настолько ебанутый.
Да не стесняйся, здесь все свои.
Зачем на дваче то об этом спрашивать? Хостер отвалился.
https://github.com/godotengine/godot-website/issues/648
> реализована смена дня и ночи
О, не дописал. Там позиция солнца автоматом привязывается к имеющемуся в дереве DirectionLight3D и вращая его получаем движение солнца по небу, в т.ч. закат и восход.
>WARNING: ObjectDB instances leaked at exit
Точнее, не так. А надо ли с этим что-то делать? Ну, то есть, всё равно же приложение закрывается; движок и сам за собой подчистит, да и ОСь тоже проверит, чтоб ничего не оставалось.
Или как? Или надо обязательно перед выходом всё очищать?
> надо обязательно перед выходом всё очищать?
Надо.
Приучайся к чистоте смолоду.
Срочно. Решил попробовать в годот вкатиться. Мне даже кешированный запрос с загрузкой файла не отдавал данные
Так ссылки на сборки ведут сюда
https://downloads.tuxfamily.org/godotengine/
Сами сборки делаются тут
https://github.com/godotengine/godot/actions
А документация сюда
https://readthedocs.org/projects/godot
Остаются ассеты, но там в кеше ссылки на гитхаб есть.
И форум Q&A, вот это ценно.
А в остальном это просто лендинг с новостями.
Все, вкатывайся без проблем.
Это не для полноценного девелопа, это если у тебя в метро внезапная идея пришла и хочется немедленно обкатать, а до твоей станции с полноценным пекой ещё далеко.
Т.е. с планшета я не смогу сделать игру для этого же планшета без ПК?
У меня в игре покадровая анимация, но анимация рук и тела может отличаться. И чтобы не делать каждый раз новый спрайт, захотелось части тело анимировать отдельно.
Добавить новый трек с анимациями рук годот не дает. А при таком использовании animationplayer они перекрывают друг друга и показывается только один
Как все это дело разделить корректно, чтобы я мог тонко настраивать, какую именно анимацию рук/тела показывать?
Кури Animationtree и там blend. Погугли как в контроллерах делают, там как раз смешивают например анимацию ходьбы и прицеливания с рук. Там еще есть галочки какие использовать кости. https://docs.godotengine.org/en/stable/tutorials/animation/animation_tree.html
https://youtu.be/6TsdmFvkw9w
>загружается 15 секунд
>на Юнити 4 секунды
>весят одинаково
>3д анимации не работают
>мешы тупо не загружаются
>тач контрол не работает
мне нравится годот но тут уже ничего не сделаешь, для яндекс игр только унити
Это у тебя в 4-ке что ли? В 3 ке на джемах часто делали 3д экшоны, с мешами и анимациями все было нормально. Время загрузки конечно не быстроею
На 3ке, десктоп без косяков, но при запуске с андроида все вышеперечысленное
>большой 2D мир (вид сверху) без пролагов?
Зависит от плотности контента на экране и в твоих чанках. Если у тебя низкое количество уникальных спрайтов на экране, то тормозить нечему. Если у тебя есть места скопления множества уникальных спрайтов, то на слабом компьютере игра может тормозить во время загрузки и отображения тяжёлого чанка (с уровневой системой это не критично, а вот в бесшовном мире будет напрягать игрока). Также зависит от того, нужно ли тебе обрабатывать что-то далеко за пределами экрана или мир за кадром может оставаться в замороженном состоянии. Также зависит от максимальной скорости персонажа, т.к. чем быстрее движение, тем чаще нужно загружать чанки, и если скорость ничем не ограничена, рано или поздно достигается предел ресурсов любого компьютера.
>>875156
>на реализацию чанков потратишь много времени
Базовая чанковая система тривиальна и делается за вечер. Тебе всё равно придётся делать какую-то свою систему сохранения и загрузки состояния мира, если ты делаешь что-то сложнее платформера. Чанковая система - лёгкая надстройка над системой сохранения и загрузки, потому что всё, что она делает - выборочно сохраняет и загружает отдельные фрагменты мира.
>>875160
>по периметру расставляем Area
Не нужно, это плодит лишние сущности.
Делаешь что-то такое:
- Game
- - Map
- - - Chunk1
- - - Chunk2
- - - Chunk3
- - - ...
- - - Player
- - - Mobs
Проверка принадлежности Player к одному из чанков выполняется двумя операциями деления его координат на размер одного чанка (чанки обычно одного размера, этим они отличаются от классических игровых уровней), после чего можно поставить в очередь загрузку необходимых чанков и выгрузку лишних (очередь снизит пиковую нагрузку). Аналогично с мобами, если они могут переходить между чанками и сохраняться в них.
Нет, если планируется делать большую карту из множества разных по форме и размеру фрагментов, скрепляя их между собой "порталами" для бесшовной загрузки, тогда твой подход с облепливанием Area имеет смысл. Можно сделать универсальную ноду-портал с полями для указания следующего фрагмента карты с точкой входа в него, а дальше можно будет сравнительно быстро скреплять между собой фрагменты геометрически невозможными способами (т.е. общую карту невозможно отобразить на двухмерной плоскости). Но я бы не стал называть такой подход "чанковой системой", даже несмотря на то, что в результате получается большой бесшовный мир. Всё-таки вместо квадратных чанков тут произвольные куски и переходы могут быть совершенно любыми, а не только в декартовой системе координат...
Но для обычного бесшовного 2D мира подход с Area не имеет смысла, т.к. чанки одного размера и располагаются в одной плоскости по сетке. Area имеет смысл размещать на входах в пещеры и дома а-ля jRPG, ради удобства левел-дизайна, т.к. такие входы могут быть в произвольных точках карты, а переходы на границах стандартного квадратного чанка расставлять - бессмысленное захламление сцены нодами и потенциально лишние операции на проверку коллизий в движке, что может стать проблемой, если чанки сравнительно маленькие (скажем, на экране умещается несколько десятков чанков при максимальном отдалении камеры - это уже больше сотни лишних Area).
Попробовал свою игрулю, тоже за 15 секунд до игровой сцены, да вроде терпимо. Надо посмотреть, может если сначала только легковесное меню загружать, быстрее будет. И вообще посмотреть нельзя ли на pck разбить и грузить динамически.
>гридмап
>мультимеш
Я не знаю, что они там в 4.0 натворили с гридмапом, но в тройке гридмап внутри оптимизируется через мультимеш следующим образом: в настройках гридмапа указаны размеры "чанка" (по умолчанию вроде бы 8x8x8), для которого создаются отдельные мультимеши на каждый использованный в чанке тип блока.
>>875848
>50,50,50 блоков
Если у тебя настройки по умолчанию, то это примерно 343 мультимеша на каждый тип блока, при условии, что каждый чанк заполнен хотя бы одним блоком одного типа. Тебе стоило бы увеличить размер чанка в настройках гридмапа и посмотреть, как это повлияет на производительность.
Мне лично гридмап неудобен тем, что он отнимает много времени на добавление/удаление блоков. Т.е. гридмап достаточно оптимален пока статичен, но частые модификации слишком медленные. Как я понимаю, задержки вызваны необходимостью пересоздать мультимеш на каждое добавление блока. Жаль, что не догадались сделать функции типа glBegin/glEnd.
>Эрпогэ - вершина геймдева.
Спорно. Хотя бы потому, что есть ММОРПГ.
Алсо под "РПГ" обычно понимают "бей мобов, дрочи циферки, продавай лут", а не килотонны сюжета.
>А Геймдев - вершина айти.
Опять же спорно, потому что есть ПО для космических аппаратов и прочих систем повышенной опасности... Это не какие-то игрушки, слепленные из говнокода и вызывающие перегрев у самых мощных игровых ПК.
>Самая простая игра сложнее самого навороченного КРУДа.
Конструкторы игр давно позволяют сделать свою собственную, уникальную игру любому дошкольнику, просто тыкая на забавные пиктограммы. Кодинг сведён до нуля, достаточно сделать картинки.
>Самая простая эрпогэ сложнее самых навороченных кликеров.
Опять же не всё так просто, потому что кликеры - это максимально редуцированные РПГ. Если в РПГ ты вынужден прорываться через тонны лишней графики и скучных букв для дроча на циферки, то кликер избавляет тебя от этой рутины, давая доступ напрямую к дрочу циферок. А достаточно сложный кликер может иметь столько сюжета и уникальной графики, сколько редко найдёшь в поделках на рпг мейкере с его тайлсетами по умолчанию, которыми школьники завалили все интернеты.
>Мне удивительно видеть, как люди без опыта в айти лезут в геймдев.
Да ты сам поди школотой был, когда первый раз задумался о разработке собственной игры. В айти люди идут чаще всего не по собственному желанию, а потому что там предлагают много денег тем, кто шарит в компах. В геймдеве же всё наоборот: желающие создать игру вынужденно начинают шарить в компах. Вряд ли кто-то мечтает верстать сайты, поднимать сервисы и делать запросы к базам данных, зато многие мечтают создать нечто похожее на игру, которая впечатлила их в детстве. По-моему, это должно быть очевидно любому, кто хоть немного наблюдал за инди геймдевом...
Я почитал, и у Годота пока вообще проблемы с 3д браузерками - на эпле особенно, да и андройде полно косяков, которые надо безумными костылями лечить. Буду следить за его развитием, т.к. легковесный и бесплатный, но для ковки железа пока унити
Шо поделать, у тебя специфичные требования - чтоб на мобилке, но в браузере. Для мобилок так то нативные приложения делают.
Для веба вообще много легковесных рендеров, я прямо на three.js игры продавал.
>Я вот в ужасе представлял, какой огород мне придется городить, чтобы ждать завершения вражеских анимаций в их ход, а тут оказывается, что я могу тупо во вражеский ход пройтись по всем врагам циклом.
Этот огород? Или что ты имеешь в виду?
>signal game_over()
>var whose_turn: int = 0
>var units: Array = []
>func _ready() -> void:
>_ units = get_children()
>_ for unit in units:
>_ _ unit.turn_done.connect(next_turn)
>_ units[whose_turn].make_turn()
>func next_turn(dead: bool) -> void:
>_ if not dead: whose_turn += 1
>_ else:
>_ _ if units[whose_turn] is Player: game_over.emit()
>_ _ else: units.remove_at(whose_turn)
>_ whose_turn %= units.size()
>_ units[whose_turn].make_turn()
Я правильно понял, что ты хочешь сделать так?
>signal game_over()
>var units: Array = []
>func _ready() -> void:
>_ units = get_children()
>_ run()
>func run() -> void:
>_ while true:
>_ _ var j: int = 0
>_ _ while j < units.size():
>_ _ _ units[j].make_turn()
>_ _ _ await units[j].turn_done()
>_ _ _ if units[j].is_dead():
>_ _ _ _ if units[j] is Player: game_over.emit()
>_ _ _ _ else: units.remove_at(j)
>_ _ _ else: j += 1
Лично мне первый вариант больше нравится. Не вижу никакого преимущества у второго варианта...
>я прямо на three.js игры продавал.
>тут тупо каждую 3д модель надо сразу со всеми анимацими экспортировать, а если нужно добавить анимацю, то весь ассет с нуля переимпортировать
Таки в чём проблема? У тебя там модель на 100500 терабайт лепнины? Просто закинул в папку и через 0.001 секунды всё импортировалось.
Вроде можно исходные .blend файлы закидывать.
>этот ваш годот
>лимитации
>в этом говне
>тупо нельзя из-за ограничений
Зачем тебе что-то всерьёз объяснять, если ты с порога ругаешься и заранее негативно настроен? Вкатывайся в движок, который для тебя не говно и безлимитный.
Лучше всего на твои вопросы ответит документация:
https://docs.godotengine.org/en/stable/about/introduction.html
Вкратце:
1. Движок опенсурс, весь код абсолютно бесплатно доступен для скачивания, модификации и компиляции без СМС и регистрации; сборки движка и игры на кастомных сборках можно распространять без разглашения изменений, даже в коммерческих целях. Единственное, что от тебя просят - оставить пометку о том, что твой продукт создан с использованием исходников Godot. Свободнее этого может быть только публичное достояние. Таким образом, умея кодить на C++, перед тобой нет никаких ограничений.
2. Если ты не знаешь C++ или не имеешь способности разбираться в чужом коде, ты можешь делать модули для движка на любом языке программирования, который умеет в компиляцию динамически подключаемых библиотек. То есть на любом серьёзном ЯП. Это не даёт модифицировать ядро движка, но может помочь с добавлением функций, для которых нужно нативное взаимодействия с целевой ОС, а также для прикручивания готовых сторонних систем на других ЯП. Можно написать всю основную логику игры как внешний модуль на любом удобном ЯП, чтобы в случае чего быстро сменить движок без переписывания своего кода.
3. Если ты вообще не программист, а вебмакака или скриптопися, то тебе остаётся только использовать доступный из коробки GDScript или какой-то другой скриптовый язык, который прикрутило сообщество, но надёжнее всего официальный GDScript. Из коробки доступно много высокоуровневых компонентов и богатое низкоуровневое API, а также возможность писать свои аддоны и модификации IDE непосредственно в самой IDE, даже без перезапусков. Т.е. ты можешь легко написать свой собственный инструмент и сразу начать его использовать, не отвлекаясь от основного проекта и окна редактора. Таким образом, большинству игр ничего кроме GDScript и встроенных функций не нужно. Ты можешь упереться в ограничение только если тебе требуется какая-то уникальная фича, доступная только на одной ОС, или если ты хочешь выпустить игру на какую-то малоизвестную платформу. Тогда придётся изучать C++ или искать кого-то, кто сможет помочь изменить исходники движка для конкретной особенной платформы.
4. Если ты яждизайнер и рассчитываешь собирать игру из блоков, адаптированных для маленьких детей, то этот движок рассчитан на людей постарше. В версии 3.x был визуальный язык, но его не смогли адаптировать для маленьких детей и поэтому вырезали из 4.x. Говорят, что при наличии желающих визуальный язык вернётся в виде опционального внешнего модуля. В общем, пока что движок не подходит для маленьких яждизайнеров, и если ты попадаешь в эту категорию, лучше посмотреть в сторону конструкторов игр наподобие Game Maker, Scirra Construct, 001 Game Creator и что там ещё опирается на создание игровой логики из визуальных кубиков... сотни их, все наступают на одни и те же грабли.
Есть один нюанс с выходом на никому не нужные игровые приставки: для сборки на них требуется их SDK, но он защищён NDA, поэтому опенсурс движки не имеют юридической возможности сделать экспорт на игровые приставки и остаться при этом опенсурс. Собственно, не велика потеря, потому что игровые приставки имеют наименьшую долю рынка и продолжают умирать, но для извращенцев и ностальгирующих есть возможность либо самостоятельно собрать движок на приставку, либо заплатить кабанчику, который подскочит и сделает это за тебя. Основные разрабы движка несколько лет планируют организовать официальный сервис для сборки на приставки, но, как я понял, это сложно организовать в опенсурс сообществе и желающих издавать игру на приставки в любом случае слишком мало, поэтому эта задача никогда не была в приоритете.
Не лень тебе перед каждым залетным вкатуном так распинаться?
Ну хуй знает, я б просто зарепортил и в движкосрач отправил. Не тот случай, когда человек заинтересован вкатиться в наше сообщество, так что ж с ним нянчиться?
А я вот заметил что годот кэширует скачанное, может у тебя унитя тоже закешировалась?
У меня вот такая демка https://gdman.itch.io/godog
(анимированная моделька, лоуполи террйн и пара коробок)
Загружается 14 секунд в первый раз, но потом 4-6 секунд стартует.
Еще видел что gotm.io делает какую то магию перепаковывая pck, но я не смог пока это повторить. Но они уверяют что упаковывают картинки и что то еще в 2 раза, экономя еще 3 секунды.
>годот кэширует скачанное
Не Godot, а браузер. Браузер скачивает все файлы и затем запускает их. Godot, как и любая другая веб-программа, находится в виртуальной среде браузера, это ограничивает возможности.
На ПК можешь открыть встроенные в браузер средства отладки и посмотреть лично, сколько времени грузится каждый файл. Кэшированные на диск файлы будут отмечены как кэшированные.
Если он такой хороший, то почему у него так мало звёзд (6.3k) и так мало контрибьютеров (225)?
https://github.com/topics/game-engine
Очевидный лидер геймдева очевиден.
>>881265
>оно занимает хуеву кучу места
На гитхабе релиз в мае по 2 Гб в двух архивах.
Блять иди создай тред по своему любимому движку и не сри в других тредах. Не создаёшь - так всё равно для выяснений, чей инсталлятор лучше, есть движкосрач. Хули ты тут забыл?
Моча, заебал на репорты не отвечать, потри уже залётного.
>определяет значимость проекта пёздачками
А кто будет баги репортить? Я?
А кто будет эти баги патчить? Я?!
А кто будет на это донатить? Я???
Нет уж, если опенсурс - то популярный.
>>881277
>чей инсталлятор лучше
Конечно же install Godot!
А мне понравился пост. Спасибо. Особенно про приставки и детей-яждизайнеров кекнул. Прямо в точку, бро!
мимоОП
Очень понравилось у юнити, простыми и понятными шагами всё делаешь, медальки дают и пр.
https://gdquest.github.io/learn-gdscript/
Я здесь пока учу сам язык (по-моему, тут уроки под старую версию годота, под 4.1 еще не запилили).
>площадка по обучению
Этот наш интернет. Алсо RTFM:
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
>медальки дают
Если тебе нужны медальки, чтобы изучить игровой движок, тогда, может быть, тебе не нужен никакой игровой движок? Юнити делает всё, чтобы заманить ньюфагов, не удивлюсь, если они лутбоксы/гачу с ассетами сделают, СОБЕРИ ИХ ВСЕ!
>>881330
>учу сам язык
Там скорее туториал по общему программированию, базовые концепции. Если уже знаешь какой-то другой ЯП, эффективнее всего прочитать это:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html
И дальше только API движка останется изучать.
>Если уже знаешь какой-то другой ЯП
Я в свое время учил питон, так что знаком со многими концепциями, но неплохо было освежить память. Кстати, я так до сих пор и не решил, пилить ли игру на годоте или лучше уж взяться за C# и начать делать на юнити. В основном отталкивает то, что для годота мало туториалов и в целом комьюнити намного меньше чем у юнити.
Запустил значит блядь, сделал максимально примитивную сценку, и что я сука вижу? CollisionShape-ы нихуя не работают, как-бы я их не сувал, я их неправильно использую или двигло действительно настолько уёбищно и придётся танцевать с бубном из-за мелочей?
Я искал и не нашел планов. Скорее всего таких планов нет т.к. это ломающее изменение для 3.х.
Тоже выбрал 3 для таких целей, хоть тайлмапы и хороши в 4. Но мне хочется стабильный экспорт в веб.
Покажи скрин как ты их расставил. Ты какой то туториал делал? Документацию читал?
Расставлял нажимая меш - создать вогнутое стат. тело, не по туторам, без документации, да и она нихуя ответов не дала, на шейпах ещё вот такая ошибка (пик).
>не по туторам, без документации
Ну так начни с них.
>Вот такая ошибка
Ну вот видишь, движок сам тебе пишет что у тебя неправильно - не униформное масштабирование.
>Ну вот видишь, движок сам тебе пишет что у тебя неправильно - не униформное масштабирование.
И? Мне это ни о чём говорит, фиксить как?
У тебя, судя по скрину, Area, а не StaticBody.
Area это область триггеров, а не стена.
Начни с туториалов, я не шучу.
>отталкивает то, что для годота мало туториалов
Туториалы полезны только полным новичкам. Godot - это просто набор инструментов, а как их использовать ты должен придумать сам. Документация Godot достаточно хорошо описывает эти инструменты, а в туториалах чаще всего объясняют высокоуровневые вещи вроде инвентаря или шкалы здоровья, которые +/- одинаково делаются на любом движке, потому что высокоуровневые.
Короче, если ты хорошо знаешь Godot, тебе подойдёт практически любой туториал от движков похожего или более низкого уровня (естественно, не подойдёт туториал про то, что делается одной кнопкой на более высокоуровневом движке).
Помню, искал какую-то идею, и нашёл её в туториале для юнити или чего-то похожего, после чего понял и быстро сделал на Godot.
>в целом комьюнити намного меньше чем у юнити
Ну, главное что разработчиков движка много и они слушают коммьюнити. У юнити со связью между разработчиками и коммьюнити объективно хуже, т.к. они там нацелены на максимизацию прибыли, а не на разработку инструмента для людей.
Год назад был скандал из-за этого, некоторые пользователи демонстративно ушли из-за этого на Godot, UE или другие движки, а акции юнити аж просели несколько раз.
И потом, даже если коммьюнити маленькое, оно может свободно модифицировать Godot на своё усмотрение, даже если разработчики пойдут куда-то не туда. В то время как коммьюнити юнити только ассеты делать может, никаких тебе свободных и независимых форков...
>не по туторам, без документации
Вот это хотя бы почитай:
https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html
Я понимаю твоё разочарование. Я сам первый раз пытался вкатиться в Godot без чтения чего-либо, т.к. интерфейс Godot создаёт обманчивое впечатление максимальной интуитивности, как в какой-нибудь видеоигре. Типа, я думал, что может пойти не так? Щас тяп-ляп и буду играть... Но нет. Психанул и забросил примерно на полгода/год. Потом решил попробовать снова, но в этот раз я попробовал пройти официальные туториалы из документации. И получилось! Признаюсь честно, за 3+ лет экспериментов с движком я не прочитал, наверное, даже половину документации, но прочитанного оказалось более чем достаточно для реализации разных моих идей.
Так что давай не упирайся, читай. Часть старой документации даже переведена на русский, как сейчас дело обстоит с переводом не знаю (даже английскую ещё не полностью проверили после повышения мажорной версии движка, но в целом всё норм).
>>881428
>Решил попробовать в 3Д разработку (раньше обходился моддингом 2Д игорь
Разработка игр с нуля сильно сложнее моддинга существующих игр, а разработка 3D игр по многим причинам сложнее разработки 2D игр. Кроме того, твои первые самостоятельные поделки гарантированно будут говном, которое придётся выкинуть или переделать с нуля. Поэтому лучше начни с туториалов по созданию 2D игр, прежде чем бросаться в 3D. Я и сам пытался начать с 3D, но теперь признаю свою ошибку.
@
>Reload Current Project
@
>Alert!
>Scene file 'box.tscn' appears to be invalid/corrupt.
Попробовал бету, называется...
Алсо, почему-то preload(”box.tscn").instantiate() создаёт экземпляр сцены без скрипта. У всех такое или у меня сцена сломана? Я попробовал создать новую сцену с такими же свойствами, она опять сломалась.
>Не упирайся
Да не упираюсь, ну это пиздец просто когда в туторах говорят мол ПРОООСТО поставьте коллижн шейп, а он через раз работает, особенно те, которые сгенерены для моделей, щас тестовую руму сделал в блендере, сунул в двигло, сгенерил коллижн шейп, а он не работает.
>говорят мол ПРОООСТО поставьте
1. Перескакиваешь с темы на тему вместо изучения по порядку с самого первого урока?
2. Читаешь/слушаешь невнимательно, пропуская абзацы или перематывая видео?
3. Мог невнимательно повторить шаги. Всякое бывает.
4. Иногда в туториалах ошибки. Особенно в устаревших. Особенно на Ютубе. Особенно от пискливой школоты.
5. Иногда ошибки нет, просто туториал плохой, из-за того, что большинство авторов туториалов не учителя. Они хорошо знают предмет, которому пытаются учить, но не знают, как правильно учить новичков.
>которые сгенерены для моделей, щас тестовую руму сделал в блендере, сунул в двигло, сгенерил коллижн шейп, а он не работает.
Реалистичная симуляция физики ресурсоёмка и склонна к ошибкам, поэтому во всех игровых движках физика ВСЕГДА состоит из упрощений и костылей.
В результате типичный физический движок реального времени, предназначенный для видеоигр, предлагает несколько видов физических тел и форм коллизии. Использование каждого вида тела и формы имеет преимущества и недостатки, поэтому выбирать нужно в соответствии с конкретной задачей.
Начнём с простого: статичные тела и динамические. Статичные тела неподвижны, поэтому движок может применить к ним больше вычислений. Динамические подвержены законам физики: движутся, вращаются, отскакивают, замедляются и т.д. Поэтому коллизии динамических тел необходимо делать проще.
Формы коллизий ещё более разнообразны. Самые простые представляют собой геометрические примитивы: в 2D это круги и прямоугольники, в 3D это сферы, параллелепипеды, цилиндры и т.п. Простые формы очень важны, потому что позволяют физическому движку использовать быстрейшие алгоритмы. Как правило, намного эффективнее составить большой физический объект из этих примитивов: игрок не заметит разницы, а игра будет работать быстрее и движок будет реже допускать неизбежные ошибки.
Следующей по сложности идёт выпуклая форма. Как следует из названия, эта форма коллизий изображает сложное тело, но оно всегда выпуклое. Вычисления сложнее, но всё же выпуклость позволяет экономить, поскольку формула проверки вхождения точки в выпуклое тело намного проще произвольного тела. В некоторых случаях может быть лучше использовать одну или несколько выпуклых форм, чем пытаться повторить сложную форму базовыми примитивами.
Естественно, одним выпуклым телом не симулировать коллизии помещения или пещеры. Поэтому для особо сложных случаев используется самая тяжёлая форма коллизий - т.н. "тримеш". Эта форма состоит из треугольников точно так же, как обычный 3D меш, но оптимизирована для физических вычислений. Однако вычисления всё равно очень сложны (для компьютера и разработчика движка), поэтому такие формы можно использовать лишь для статических тел.
Есть и другие специальные формы и тела, например, специальная форма для карты высот и "мягкое" тело, но ты пока этим голову не забивай.
Вот это всё ты должен был знать после чтения базовой документации. Там это так или иначе объясняется, ибо это базовая информация для разработки игр.
Конкретно в твоём случае тебе скорее всего нужен один StaticBody3D и множество CollisionShape3D в нём, которые ты должен вручную заполнить примитивами - в основном это будут параллелепипеды для стен и объектов, визуально похожих на коробку.
Конечно, ты можешь сгенерировать тримеш для целой локации. Но это может быть весьма неэффективно, особенно если у тебя очень тяжёлая геометрия меша. Всегда в первую очередь рассматривай примитивы - параллелепипеды, сферы, цилиндры, затем выпуклые формы, и только на крайний случай бери тримеш.
О, слухай, к тебе вопрос, если ты спец по кискам коллижнам. Вот я собираюсь делать шутан по типу вольфа3д, трехмерный, но в одной плоскости, и с квадратно-гнездовой картой. Как мне лучше колижны для гридмапы делать, с точки зрения производительности - тримеши, чтобы они потом запеклись в один большой тримеш, или кубы?
>колижны для гридмапы
>они потом запеклись в один большой тримеш
Хм? А такое вообще возможно? Я не видел функций склеивания тримешей. GridMap, насколько понимаю, создаёт один StaticBody на один "чанк", заполняя его коллижен шейпами. По моим тестам, можно пихнуть примерно тысячу шейпов в один боди, прежде чем начнутся проблемы с производительностью.
Я проверил в коде движка. Да, всё верно: есть один статикбоди на чанк (октант), заполняется шейпами максимально тривиально, вот в этой строчке:
https://github.com/godotengine/godot/blob/master/modules/gridmap/grid_map.cpp#L632
>PhysicsServer3D::get_singleton()->body_add_shape(g.static_body, shapes[ i ].shape->get_rid(), xform × shapes[ i ].local_transform);
Короче, лучше использовать примитивные кубы.
Хотя есть вероятность, что тримеши одного статикбоди склеиваются где-то внутри физического движка, но я бы не надеялся на это.
В GridMap, PhysicsServer3D или в Godot Physics 3D?
В GridMap, как видишь, шейпы не склеиваются.
Самое надёжное - провести краш-тест, заполнив гридмап огромным количеством кубов.
Я мельком глянул код физики - не нашёл ничего про склеивание тримешей. Они обрабатываются так же как и остальные виды шейпов, без склеивания.
Поищи сам, если хочешь:
https://github.com/godotengine/godot/tree/master/servers/physics_3d
Возможно, там, где ты это читал/слушал, перепутали склеивание нескольких тримешей в один шейп с комбинацией нескольких шейпов в один боди.
Там вроде предупреждение перед запуском - делайте бэкапы.
4.1 пока не ковырял, вообще 4-ку пока отложил, у меня тут пара проектов на 3-ке поперла.
>делайте бэкапы
Так я новый проект начал делать для теста. Менеджер проектов 4.1 про проекты 4.0 пишет что-то типа:
>в данной версии могут отсутствовать функции
- типа в 4.1 что-то вырезали? Не слежу за новостями.
>вообще 4-ку пока отложил, у меня тут пара проектов на 3-ке поперла.
Не особо ждал выход 4.0, но как-то грустно оставаться на устаревшей версии, когда всё самое интересное делается исключительно для 4.х. У меня нет какого-то большого проекта и терять особо нечего, поэтому думал постепенно перейти на 4...
Концепция игры последние лет пять была такой:
1. Игрок выбирает параметры своего персонажа и нового игрового мира (место, масштаб и т.п.).
2. Игра процедурно генерирует конечную карту с городом по центру и начинает моделировать жизнь его жителей на каком-то уровне точности.
3. Игрок делает что захочет, зарабатывает деньги, репутацию, отношения с жителями, обустраивает себе дом, возится с машиной и т.д.
Что я делал? В основном пытался сделать интересную процедурную генерацию, но не смог придумать ничего интересного. Жителей я вообще забросил, потому что без строго сформулированного мира непонятно, какие задачи они должны решать. Да и чем конкретно игроку следует заниматься я тоже не особо представлял.
Сейчас я размышляю о том, как можно переделать эту концепцию во что-то более реалистичное и интересное, оставив суть проекта без изменений.
Меня вдруг осенило, что если игрок играет в одном и том же городе, имеет в нём что-то ценное, то у него нет мотивации начинать игру в новом городе, а тогда вся эта процедурная генерация не имеет никакого практического смысла. Я даже думал о том, чтобы отказаться от процедурки в пользу ручного редактора карты, но меня это не привлекает. То есть лично мне по кайфу копаться в алгоритмах генерации, но базовый геймплей не расположен к использованию этой генерации. Значит, нужно менять геймплей.
Вторая важная проблема - в симуляции жителей. Мне хотелось максимально "честную" модель, которая не использовала бы обманные манёвры как это обычно происходит в большинстве игр. Понимаю, это сложно реализовать, но проблема в том, что игрок не увидит и процента всей этой сложности, кроме процентов в диспетчере задач, лол. Было бы приятно развивать отношения с одним NPC-персонажем, но жизнь сотни фоновых персонажей смысла не имеет.
Одним из решений мне видится превратить игру в некое подобие роад-муви: игрок может двигаться по дорогам бесконечно долго, пока игра будет генерировать новые города с временным глупым населением и полностью забывать те, из которых игрок уехал. В этом случае процедурная генерация раскрывается в полной мере, а на симуляцию жителей можно с чистой совестью положить большой гаечный ключ, которым игрок ремонтирует свой транспорт. Также игрок мог бы взять с собой NPC, обменять свой ржавый запорожец на автодом, заполнить его мебелью и т.д.
Похожие идеи у меня были и раньше, но я не пытался применить их к этому проекту. Как минимум не ясно, что должно двигать игрока вперёд кроме любопытства и скуки, потому что надвигающийся апокалипсис или другую угрозу я делать не хочу. Если у игрока полный контроль над транспортом, он может и назад повернуть, верно? Будет ли слишком странным встретить на пути назад совершенно другую местность? Или ту же самую местность с теми же самыми жителями, которые вообще никак не изменились за прошедшее в игре время? В общем, такие вопросы в своё время заставили меня отказаться от бесконечной генерации мира а-ля Майнкрафт.
Самое смешное, что временное название проекта на идею роад-муви ложится лучше всего того, что я рассматривал в прошлом, лол.
Видел игры с похожей концепцией, но там слишком примитивный геймплей и мир, уровня раннеров. Не хочу деградировать до уровня раннеров, поэтому базовый геймплей остаётся а-ля GTA.
Помню, большую часть времени регулярно генерировал заново ландшафт/город/дома, вообще не задумываясь о сохранении и загрузке, потому что они мешали бы тестировать генерацию. Если бы я сделал полноценный геймплей и начал играть, тестировать генерацию можно было бы только в отдельном новом мире. Сейчас думаю, что с геймплеем "бесконечное путешествие по дороге" генерацию можно тестировать на одном и том же сохранении, ведь города как таковые сохраняться вообще не должны.
Одной из идей было развивать сад/огород и подобную недвижимость. Однако, что мешает дать возможность сажать растения прямо на транспорте? Видел такое в некоторых играх. Тем более игрок может всегда остановиться, разбив временный лагерь или сняв на время какой-нибудь домик. Впрочем, опять не ясно, что должно стимулировать игрока на движение, если он может сидеть на одном месте.
А нужно ли вообще стимулировать к чему-то? Я вроде песочницу пытался сделать...
С технической стороны думаю сделать генерацию бесконечным графом: узлы - города и развилки, рёбра - длинные междугородние дороги. Квадратно-гнездовой подход останется, надеюсь придумать больше разнообразных блоков-тайлов. Генерировать карту высот мне не очень нравится, больше привлекает ощущение автоматизированного конструктора Лего. Может быть, доделаю редактор деталек а-ля встроенный инструмент моддинга, нужно подумать.
Думаю продолжить пока на Godot 3.x, а то 4.x намного больше проблем имеет.
Кого-нибудь здесь это вообще интересует?
>>881451
>Помню, искал какую-то идею, и нашёл её в туториале для юнити или чего-то похожего, после чего понял и быстро сделал на Godot
>Пикрил кто-нибудь помнит?
Конечно, редкий приятный проект на дваче, одна из причин все еще иногда заходить в /gd
Насколько тяжко будет в годоте запилить клон Горячей Майамы человеку, не слишком хорошо погромирующему?
Или уже есть шаблончик под такое
>Насколько тяжко будет в годоте запилить клон Горячей Майамы человеку, не слишком хорошо погромирующему?
Ну давай разберём по частям тобою написанное.
1. Что значит "тяжело"? Что ты готов превозмогать, а что заставит тебя всё бросить и уныть?
2. Что значит "клон Hotline Miami"? Ты хочешь бездушную копипасту или готов импровизировать?
3. Что значит "не слишком хорошо"? Что ты реально программировал, на чём, смог ли понять свой код?
>шаблончик под такое
Поищи сам. Hotline Miami - топдаун шутер, весьма популярный жанр, что-то наверняка должно быть.
https://duckduckgo.com/?q=godot+top+down+shooter+template
В общем, представил как это будет, потестил прототип с одной прямой дорогой, подумал над вариантами.
Однозначно хочу чтоб было высокое разнообразие дороги, а не сплошная прямая трасса. Петляющие между холмами участки, участок спуска с отвесной скалы, участок в гору, участок с мостом через реку, участок через какое-нибудь визуально приятное поле/луг, участок вдоль моря, редко встречающиеся одинокие домики и т.п. Одним словом, чтоб было на что посмотреть и чтобы не было бездумного зажимания кнопки W, иначе смысл теряется.
Да, можно сделать всё это вручную, но тогда это будет просто набор случайно выпадающих кусочков - проехав по одному, остальные будут слишком похожими, ну и смысл тогда куда-то ехать, если тебя ждут только повторы уже виденного? А как это чисто процедурно генерировать я вообще не представляю, слишком большое количество разных вариантов, которые нужно учитывать.
Нужно применить декомпозицию, от общего (дорога без конца) к частному (участки дороги). Вообще, мне следовало бы концепт-артов накидать сначала...
На одном только вдохновении далеко не уедешь, а когда я тот пост набирал - думал за один вечер до интересного прототипа довести(
>>881664
>Конечно, редкий приятный проект на дваче, одна из причин все еще иногда заходить в /gd
Спасибо, конечно, хотя не верю, что ты это серьёзно. В разделе полно достойных, полноценных игр, а я несколько лет ковыряю прототип, в котором до сих пор ничего нет, кроме смутных хотелок чего-то.
>>881667
>Не слишком масштабно для одного?
Смотря как посмотреть. Реализм не потяну, но я и не пытаюсь в него. На данный момент проблема не в потенциальном масштабе, а в том, что я не знаю точно, что именно я хочу/стоит реализовать.
Геймдизайнер из меня точно никакой...
>В разделе полно достойных, полноценных игр, а я несколько лет ковыряю прототип, в котором до сих пор ничего нет
Абсолютно искренне. Твой прототип выглядит очень выгодно на фоне - либо доделанных, но неинтересных или некрасивых игр (пиксельный шутемап, майнкрафтовый рогалик, прыгаюший квадрат с меню, проклятые анимепанцу), либо недоделанных и некрасивых (котлоферма), либо недоделанных красивых (что-то про летающую аниме с копьем, некоторые заброшенные поделия с твг, вроде пинк девочки). А больше ничего и не вспоминается. А, еще есть пара типа-реализмов про постсовковые дворы, но это другая направленность, у тебя как то более жизнерадостно. Ну ты продолжай пилить прототипы, так и запилишь что то.
>будут слишком похожими, ну и смысл...
Подумал ещё и ВНЕЗАПНО вспомнил, что от честной генерации а-ля майнкрафт толку ровным счётом ноль, потому что даже если все участки карты технически разные, субъективно разница между ними как между тарелками одной и той же каши.
Тогда решил всё-таки собрать прототип на вручную смоделированных блоках и... получились какие-то рандомные американские горки?.. Кстати, пробовал ехать как можно дольше - спустя 40 км (!) надоело ждать проявления этих глитчей:
>There may also be rendering and physics glitches due to floating point error in large worlds. You may be able to use techniques such as orienting the world around the player (rather than the other way around), or shifting the origin periodically to keep things centred around Vector3(0, 0, 0).
Если делать дорогу реально бесконечной, то, конечно, сдвигать мир придётся. Но для обычной игры должно хватать точности без этого сдвига. Я про ГТА, в космосимах совсем другие проблемы, конечно.
В любом случае, я вспомнил, что в попытках сделать генератор забыл о самом главном - геймплей. Его нет. По идее, главным должен быть геймплей-луп:
>A gameplay loop consists of a cycle of actions that you repeat over and over within a game.
Раньше идея была "просто жить в городе", так что я вообще не представлял, что именно делать нужно.
Теперь... Допустим, можно так:
1. Едем куда глаза глядят по дороге;
2. Доезжаем до случайного "города" (3.5 домика);
3. Делаем мелкие задания (?) жителей, зарабатывая деньги на всякие шмотки, запчасти, топливо и т.п.;
4. Едем дальше, поскольку контент размазан между городами, в одном городе никогда нет 100% контента. Каждый город своего рода процедурный лутбокс. Ну, можно сделать ресурс каждого города конечным. Скупил всё что мог - пополнения товаров не будет.
Плюс можно напридумывать много побочных лупов, особенно в виде случайных событий на дороге. Типа подбросить кого-то до города, или поменять колесо. Следить за параметрами персонажа, чтобы не уснуть прямо за рулём в дороге, делать остановки.
Что делать с возможностью ехать в обратном направлении пока не знаю, нужно ещё подумать. Наверное, стоит сохранять на диск минимум один город вместе с дорогой до него. Потом удалять.
Глобальную мировую карту генерировать не хочу...
>>881868
>Твой прототип выглядит очень выгодно на фоне
Эээ, ну, даже не знаю. Я просто накидал кислотных коробок и мучаюсь с кувыркающимся VehicleBody.
Графика плейсхолдерная, чтобы прикинуть габариты и запилить геймплей раньше графики. Но да, хочу что-то сравнительно жизнерадостное...
>некрасивых игр
>проклятые анимепанцу
Что там некрасивого, вроде норм. Тоже хочу что-то похожее на аниме сделать, но это сложно. А готовые модельки использовать не хочу.
Просто лорно объясни почему города пропадают и не парься с возвращением. Будет что в какую бы сторону игрок не ехал он едет вперед и там всегда что-то новое.
1. Делаете первую, прямую секцию дороги.
2. Кидаете модификаторы Array и Curve.
3. Создаёте Path или другую кривую.
4. ??? ...играете настройками, сабдивом и т.д.
5. Восхитительно плавная дорога!
>>881895
>лорно объясни почему города пропадают
Была подобная идея для другой игры, а в этой я планировал сделать относительно наш мир. Да и объяснение ещё придумать нужно адекватное.
>Будет что в какую бы сторону игрок не ехал он едет вперед и там всегда что-то новое.
А если пропустил/забыл что-то и хочешь назад? Много причин вернуться хотя бы в последний пройденный город. Так что некоторый "хвост" стоит поддерживать. Я бы и сам этой фичей пользовался.
Представь, потерял капот по дороге, в городе нашёл подходящий, но денег не хватает, поехал дальше и случайное событие дало достаточно денег, едешь обратно весь такой в предвкушении, а там ДРУГОЙ город и никакого капота в продаже нет...
>Была подобная идея для другой игры, а в этой я планировал сделать относительно наш мир. Да и объяснение ещё придумать нужно адекватное.
Так хуле проблема? Пусть игрок сюжетно от чего-то бежит. Скажем, от закона или карточных долгов. Если вернуться в прошлый город, тебя там встретит полиция или мафия, которой ты должен. Получится такое-то охуенное роуд-муви. Если вариант с долгами, то это можно даже сделать целью игры (хотя бы для одной из концовок) - заработать денег, чтобы его вернуть.
>сюжетно
Ааа... Ясно, забыл сказать, что сюжета нет, игра не должна обязывать игрока делать что-то по сюжету.
Вот в ГТА тебе игра постоянно меткой на карте напоминает, ещё персонажи названивают. Иди сюда, делай то, делай это, вот 50$ на чай, теперь уходи, но оставайся на связи до следующего задания.
А в Майнкрафт есть дракон и даже титры, но игра не сообщает об этом, не показывает стрелочкой, куда идти и что делать. В Террарии есть порядок боссов и игра может наслать на тебя события, но она не принуждает тебя развиваться и вызывать боссов.
Вот сеттинг и геймплей меня в ГТА привлекает, но сюжет всегда казался лишней рутиной. Я зашёл покататься по городу и поиграть в мини-игры, а с меня тут требуют что-то, задолбали...
Так что в своей игре я задумывал 100% песочницу без принудиловки. Заспавнился в городе и делаешь что пожелаешь в рамках доступных возможностей. Не торопишься никуда, не занимаешься рутиной. Хочешь быть гангстером в бегах - будь, хочешь быть кем-то другим - тоже можешь без проблем. Всерьёз думаю о создании грузовиков и грузоперевозок - но только как опция, как та побочная миссия в GTA SA. Не хочешь возить грузы - не проблема, игра не заставит.
Ладно, эти вопросы можно потом решить.
Я не говорю тебе прямо прописывать сюжет. Просто дать установку - вот мол, нельзя вернуться назад потому то потому то. Или вообще пусть ГГ при попытке вернуться в позапрошлый город говорит "Я не могу вернуться назад" и многозначительное многоточие, а еще лучше - придумай побольше всяких подобных ничего не значащих, но меланхолично звучащих фраз и выдавай их случайно.
>я не могу вернуться назад...
>я оставил былое позади...
>прошлое может настичь меня там...
Критики тебя потом на руках носить будут, а игроки будут СПГСить как умалишенные.
Меня больше волнует, что делать со всем остальным, что вокруг дороги. Растягивать тайлы на несколько километров в ширину? Делать горы, заборы и сплошные стены из деревьев а-ля первая Мафия (частично вдохновлялся одной загородной миссией, там какая-то очень длинная дорога с кучей поворотов и ландшафт прикольный, но съехать с дороги нельзя из-за заборчиков)? Или прикрутить карту высот с шумом Перлина? Я уже не уверен, что это опенворлд, если мир вытянут в бесконечную кишку с невидимыми стенами по бокам, даже если по пути этой кишки встречаются локации-города.
Блин, пока что получается что-то ближе к аркадным гонкам-раннерам, чем к ГТА.
Но, может, оно и к лучшему.
>Меня больше волнует, что делать со всем остальным
Тебя должно больше волновать что ты сам настолько не знаешь что от игры хочешь, что у тебя даже нет понимания что же у тебя за кор механика.
Я ХАЧУ СДЕЛОТЬ СВОЮ ЖТА С ПРОЦЕДУРНЫМ ГОРОДОМ ГДЕ ХЗ ЧТО ДЕЛАТЬ И МЕЖДУ ТАКИМИ ГОРАДМИ МОЖНА ЕЗДИТЬ это не кор механика и даже не примерное описание идеи.
Что ты хочешь от игры?
Чем является твоя игра?
С ответа на эти вопросы надо начинать и от этого уже плясать, а не прокрастинировать задумываясь от том что же будет по бокам дороги. Это детали, а думать нужно о сути.
>ты сам настолько не знаешь что от игры хочешь, что у тебя даже нет понимания что же у тебя за кор механика
Ты абсолютно прав, анон.
>ХАЧУ СДЕЛОТЬ СВОЮ ЖТА
>это не кор механика
А какая кор механика в самой ЖТА?
>Что ты хочешь от игры?
Фундамент для добавления всякого интересного.
>Чем является твоя игра?
Экшн-адвенчур песочницей с симуляцией жизни.
Смотри, в жта я могу просто зайти, гоп-стопнуть понравившуюся машинку и несколько ирл часов совершенно бесцельно нарезать круги по городу. Это достаточно интересно, но надоедает, ведь:
1. Город статичный и никак не меняется. Один раз его изучив, ты ничего нового в нём не найдёшь. Даже взорвав тысячи машин и убив тысячи людей ты ровным счётом ни на что не повлияешь.
2. Человечки - тупые дроны на замкнутых маршрутах, к которым игрок может только насилие применять. 3.5 случайных сценки погоды не меняют. Только у проституток есть осмысленный выбор Y/N (GTA SA) или аж три строчки диалогового меню (GTA IV, V). Механика свиданий максимально линейная, а свидабельные персонажи захардкожены.
3. Домики - пустые кубы с текстурами, не считая 3.5 локации где что-то есть и 1.5 локации где есть интерактивные предметы с мини-играми. Не говоря о том, насколько абсурдный урон они выдерживают.
4. Машинки настолько аркадные, что способны ехать даже после сплющивания в лепёшку (GTA IV). Но ещё больше огорчает мгновенная починка любого урона и исчезновение оставленного транспорта.
5. Графон "типа реализм" навевает уныние, будто вышел на улицу и увидел знакомый гадюшник. Вбухали тонны бабла чтобы нагнетать уныние...
6. Дурацкая сюжетка про мамкиных гопников. Если бы я хотел катсцены и диалоги, я бы зашёл на ютуб...
В общем, я мечтал решить хотя бы часть этих проблем своими силами, но не модом, а созданием полностью независимой игры с аналогичным фундаментом.
1. Чарактер контроллер я накидал по-быстрому.
2. Несколько машинок я накидал на VehicleBody.
3. Генератор города я сделал аж в нескольких разных вариантах, но контентом наполнять их не стал, потому что кататься по "квадратно-гнездовым" улицам оказалось чуть более чем уныло, а что-то интереснее придумать (!) не получилось.
4. Неигровых персонажей я пробовал делать, но их проблема в отсутствии жёсткого фундамента. Нельзя сделать модель человека без тела, а тело без среды обитания, а среды обитания у меня нет, ведь я не смог придумать интересный генератор среды.
5. Графику, физику машин отложил ещё дальше: без фундамента это кажется лишней тратой времени.
Подумал вот, что можно компенсировать нехватку интереса от одного города последовательной генерацией множества разных поменьше, даже если они будут неполноценными в плане симуляции жизни, которая игроку всё равно не слишком заметна от первого лица (что там за закрытыми дверями происходит... а какая разница?). Перенести приоритет игры с полномасштабной симуляции целого города на симуляцию всего нескольких (свидабельных) персонажей вокруг игрока, в прямом смысле забывая весь остальной мир вместе с персонажами. Тогда можно просто ехать в одном направлении, получая новый контент и/или новые комбинации старого контента и множество случайных ситуаций по пути. Тем более что езда по длинной загородной дороге имеет чуть больше смысла, чем нарезание кругов по городу площадью в один жилой квартал в реальном мире. Алсо это органично и даже незаметно вписывает лутбоксы в игровой мир, а без них никуда, лутбоксы - это кровь любой современной игры, без них никто играть не будет (тут я пытаюсь пошутить, но это почти не шутка, к сожалению).
P.S. Из сливов GTA VI пришёл к выводу, что фиксить обозначенные проблемы рокстар не собираются, так что оригинальная ГТА мне пока что не конкурент. Посмотрим, что они придумают в семёрке...
> А какая кор механика в самой ЖТА?
- Получил миссию.
- Выполнил задачи миссии.
- Получил деньги.
- Потратил деньги.
Повторить до конца игры.
>>882096 (OP)
>>882096 (OP)
>- Получил миссию.
>- Выполнил задачи миссии.
Лол, больше всего времени потратил на бесцельные скитания по миру и всякие эксперименты с физикой, машинами, пешеходами и т.д. Потом "ой, наверное, нужно миссии проходить..." и не могу вспомнить, кто эти люди и почему я им что-то должен. Поэтому предпочёл бы больше мелких, не связанных друг с другом заданий (даже процедурных и повторяющихся, как в GTA Online), чем сюжетку с длинной историей... А потом кто-то спорит, утверждая, что ГТА не песочница...
>- Потратил деньги.
>Повторить до конца игры.
Самое смешное, что во всей серии GTA это одна из главных проблем геймдизайна. ДЕНЬГИ ТУПО НЕКУДА ТРАТИТЬ. В GTA Online это "пофиксили" безумными ценниками на всякие мафынки и их модификации, ограничением на число гаражей, платой за перенос предприятия с место на место, смену декораций и т.д. Но всё равно некоторые скапливают миллиарды честной игрой, и эти миллиарды не на что тратить, ведь самое дорогое стоит "всего" чуть больше десятка миллионов. Деньги очень быстро теряют смысл, тем более в старых GTA, где покупать практически нечего. Риска потерять деньги почти нет, штрафы смешные.
Пишу логику
Компилирую логику в динамическую библиотеку под целевую систему
Подключаю её в проекте через нод-обёртку?
>Компилирую логику в динамическую библиотеку под целевую систему
Да вроде и раньше так можно было...
GDNative -> GDExtension.
> тем более в старых GTA
Ну я в основном от сан андреаса отталкиваюсь. Там набросали кучу объектов, которые надо купить для продолжения сюжета. Но и в вайс-сити надо было как минимум малибу и жёлтоетакси покупать. А что было ранее я уже не помню.
> больше всего времени потратил на бесцельные скитания по миру
Возражение уровня "а я вместо того чтобы играть с этим ботаном, швырнул ему шахматы в еблину". Нашёл чем хвастаться. Но к чести рокстара, да, песочницу они завезли добротную. Пиздюками мы все гоняли на маффынках от ментов с аснаёбом, и только повзрослев, узнавали, что там сюжет оказывается есть.
Не правильно понимаешь.
В 4 как и в 3, ты можешь как писать динамическую библиотеку, так и писать модули для движка. Написание модулей - самое скоростное решение. Ты прямо в ядре движка будешь работать с максимальной скоростью, зависящей только от оптимизации твоего кода и от железа офк. Подключение либы уже будет давать накладные расходы, которые впрочем, при грамотном кодинге никто не заметит, но зато в папке с игрой будет насрано либами. Но либы ты можешь написать на любом языке, который может в компиляцию либ. А модули движка только на крестах.
Все так играли. Мне больше всего запомнилось, как я долго и упорно пытался проникнуть на еще недоступную киностудию, подгонял автоперевозчик, использовал его как трамплин. Помню ли я что нибудь из сюжета? Вообщем то нет.
gdscript это типа брат близнец kotlin?
Корочи, сделал простеньку игру на Godot'е по концету геймплея из этого видео:
https://www.youtube.com/watch?v=J_qQ76ouWXI&list=PLgsD7taGtaBidBJSgyxcet_o2k0Kqr-e5&index=24
Но мой вариант больше под спидран заточен.
Скачать можно отсюда:
http://j33111470.myjino.ru/cells_game
(это мой хостинг с бесплатным доменным именем)
Там есть и веб-версия, но она тормозит и не у всех вообще работает. Предположительно, версия движка слишком старая (3.1) и/или проблемы с GLES2 на современных браузерах. Билды есть под винду и под Линукс, 32-х и 64-х битные.
Вот.
Перемещение: стрелки, WASD, кнопки UI.
Рестарт: пробел, Enter, R, копка UI.
Звук тоже можно кнопкой отключать или на M.
Чтобы в веб-версии управление заработало, нужно после загрузки игры на экран кликнуть, чтобы окно игры было в фокусе.
Найс. Я в старый тред запостил. Спасибо закрепу.
А перепощивать лень...
В связи с юридическим аспектом нужно сделать так чтобы пользователь распаковал файлы оригинальной игры и сунул в папку с exe моего переноса, пока прикидывал просто выдирал файлы и совал в проект настраивая всё, сейчас понял что я лучше сейчас переделаю малый объём работы, чем буду всё переделывать на такую формулу в последний момент.
Встал вопрос - как использовать файлы из одной папки с исполняемым файлом не используя скрипты и никак не упаковывая эти файлы? Желательно, но не обязательно чтобы их было видно в редакторе.
А мне не нравится, извини, ОП. Какое-то всё крупное будто сделано для смартфона. Может на https://rentry.co/ или https://markdownpastebin.com/ напишешь? Оно как-то привычнее анонимусу, пынямаешь? Ну и спасибо за старания, опчик, целую в щёчку!
Я имею ввиду следующее:
например мне надо описать стандартные для игр действия - человек бежит, стреляет.
Я беру кусок кода, копирую, меняю там минимум , чтоб соответвовало моему заданию, вуаля, все готово.
Понятно, что какой то минимум придется выучить.
Сап, я ни в движках, ни в ЯП не шарю, но слышал про godot, смогу ли я опираясь на хульен уроков/курсов по godot'у понять как сделать простенькую игору в стиле платформера например?
Сделайте мне плз несложный проектик на годоте за деньги.
Суть токова: нужно бросать два игральных кубика на бесконечную плоскость и выводить на экране количество очков.
Модель кубика есть максовская.
Игровой процесс:
1. Игрок нажимает ролл.
2. Он нажимает ролл, кубики падают сверху на бесконечную плоскость
- Краёв плоскости не должно быть видно.
- Кубики не должны укатываться за пределы камеры (можно например сделать невидимые стены, но главное чтобы кубики не вставали ребром у стены), или любой другой способ избежать укатывания.
- Изначально кубики должны быть в рандомном положении по осям + надо им придать какое-то ускорение (чтобы не падали просто плашмя без перекатов, и вообещ чтобы походило на рандом). Процесс должен быть похож на ирл (т.е. в игре д.б. нормальная гравитация)
3. Кубики упали, стабилизировались и на экране показывается оверлей с количеством выпавших очков и их суммой. Игрок может рерольнуть, goto 1.
Вроде как несложно для тех, кто открывал годот пару десятков раз.
Пишите в телегу lubitelivodki
И реально на Godot запилить что-то типо Roblox, SecondLife? Чтобы можно было онлайн бегать кучей народу.
Я пока что придумал сделать ноду которая забирает весь инпут и посылает сигналы в игру.
Нажимаешь кнопку, эта нода смотрит на какое действие ты забиндил эту кнопку - например, нажимаешь W - идет сигнал ноде игрока чтобы подвинулась на вперед немного.
Как идея?
Базовая концепция следующая:
1. Пользователь выбирает тайл
2. Пользователь ставит тайл на поле
3. Пользователь нажимает кноку сохранить
4. Тайлмапа конвертится в json (или сразу создается параллельный словарь который после сохраняется как json)
5. При загрузке просто расставляем обжекты по json'у
Тут все логично лаконично и понятно, но вопрос у меня больше по технической составляющей визуала.
Мне очевидно требуется сетка, начало отсчета координат и границы. В этом плане я выбрал пока примерно позицию нулевая позиция х:0 y: 300 16. Пределы соответствующие, слева сверху нули, снизу и справа 300 16. Интро к вопросу долгое но похуй.
То что меня волнует сейчас больше всего - как рисовать сетку? Мне нужна сетка что бы юзер не терялся очевидно. Как то разделять тайлы и прочее. Возможно даже как в оригинальном редакторе godot'a когда рисуешь что-то тайлами там такая небольшая обводка в виде сетки. У меня конечно последние недели времени много времени подумать над этим небыло, но я либо тупой либо задача реально нестандартная.
Какие есть советы?