С изучения документации. Если не можешь в инглиш, и даже в гугл-переводчик, то начат перевод официальной документации: https://docs.godotengine.org/ru/latest/
Но вообще, будь мужиком и изучи английский: https://godot.readthedocs.io/en/stable/
Вместе с движком обязательно смотри примеры, там есть всё - от платформера до чата. Примеры качаются прямо в движке через свой магазин.
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Игры, созданные глобальными кириллами: https://godotengine.org/showcase или https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Скажи "Годот круто!" https://github.com/Calinou/awesome-godot - подборка дополнений, модулей и минишоукейс от одного из авторов.
Годнота от анона:
Для приверженцев опенсорца существует возможность распрострянять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории.
Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
Все языки в одном месте: https://vk.com/topic-70467171_35982467
Тест-бенчмарк:
Веб-версия - https://govdot.herokuapp.com
Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий тонет там: >>635427 (OP)
Архивы:
1 http://arhivach.ng/thread/207802/
2 http://arhivach.ng/thread/388500/
3 http://arhivach.ng/thread/388501/
4 http://arhivach.ng/thread/388502/
5 http://arhivach.ng/thread/388503/
6 http://arhivach.ng/thread/432708/
7 http://arhivach.ng/thread/433902/
8 http://arhivach.ng/thread/436355/
9 http://arhivach.ng/thread/455461/
10 http://arhivach.ng/thread/479963/
11 http://arhivach.ng/thread/489815/
12 http://arhivach.ng/thread/494513/
13 http://arhivach.ng/thread/515567/
>>643191
Бывает такое.
Мне помогает закомментить всё и переписать заново иным образом. В процессе переписывания я в 90% случаев нахожу, где я проебался.
Помимо вывода есть ещё отладчик. Там тоже много интересного пишут.
Нашел способ воспроизвести краш с 100% вероятностью. Надо войти в режим прокладывания маршрута, и начать быстро кликать по своим зданиям, возможно, при этом немного прокручивая карту
Не знаю точно, что происходит, но в один момент вылетает ошибка. Игре кажется, что после этого с ней все в порядке, но на самом деле ей уже настал omae wa mou shindeiru.
Текст ошибки намекает на обработчик мыши и его параметры. Возможно, ты где-то не дописал аргументы?
P.s. игра не выносит ресайз окна, но это ты исправишь покурив http://docs.godotengine.org/en/3.2/tutorials/viewports/multiple_resolutions.html
Ввёл логирование с помощью файла. Доступ к логам в игровом меню (которое раньше было пустым). Если на сайте с созданием файлов все ок, то в скором времени отладка у пользователей будет без проблем. Спасибо за детальный разбор ошибки! В скором времени её поправлю и выложу новую версию.
Ты можешь поступить так, как я показывал в прошлом треде.
Пройтись в цикле по всем кнопкам и всем им подключить один сигнал.
Двачую этого.
Кроме того, у сигналов есть возможность привязки к ним любых дополнительных данных, в качестве которых можно указывать ссылку на кнопку. Таким образом, все кнопки будут выполнять один обработчик сигнала, но подавать на вход ссылку на себя:
for button in buttons.get_children():
-> button.connect("pressed", self, "on_arraybtn_pressed", [button])
func on_arraybtn_pressed(sender):
-> print(sender.name)
https://godotengine.org/asset-library/asset/514
хтмл5? Там какие-то проблемы с схоронением. При работе в браузере сохранение в файлы должно прозрачно заменяться схоронением метаданных в локальное хранилище браузера. Однако там есть куча подводных камней, с которыми я попытался разобраться, но потом хзабил.
Пока только два :
1)Как ограничить движение 2д камеры? Камера передвигается перетаскиванием мышкой и wasd со стрелочками, и если как ограничить передвижение у стрелочек я понимаю, то как с перетаскиванием неебу. Желательно чтобы при отдалении камеры колесиком я не выходил за пределы.
2) Нужно перелистывание слайдов, я примерно понимаю как это можно сделать. Нажимаешь на кнопку - выключает видимость X, включает видимость Y, еще раз выкл Y вкл Z. Но как это сделать покрасивее и удобнее? Не прописывать же вкл/выкл для 15 слайдов допустим.
1. Ограничить движение камеры точно так же, как ограничить любую переменную по диапазону: проверяешь выход за границы диапазона и отменяешь изменение.
2. Максимально абстрактный вопрос. Как сделать красиво? Нужно обладать вкусом. И сделаешь красиво. Чтобы обладать вкусом, нужно перелопатить определенное количество контента, в нашем случае игр. И тогда начнёшь понимать, что красиво, а что нет.
1. Да в общем то так же. У тебя где то выставляется координата x и y.
Насчет колесика - ну ты можешь высчитать сколько пикселей видно на экране, и на столько отступить от лимита. Наверняка и готовое решение можно нагуглить. Какую нибудь rts камеру.
2. Можно много чего сделать, во-первых массив или список. Опять же смотри пример >>643295
Эффекты можно разные сделать, затухания там.
А можно вообще просто сделать большой "уровень" и выставить твои слайды по порядку, и летать камерой.
Я ещё раз пересмотрел твой код и обратил внимание на то, что у тебя сначала открывается сейв, прочитывается, парсится в переменную, вносятся изменения и затем файл открывается на запись и записываются новые данные.
Дело твоё, конечно, но я бы не рекомендовал модифицировать сейв файлы. Только если игра предполагает. Типа, как в Андертейле, когда главный злодей игроку сейвы трёт.
В основном же, я предлагаю тебе хранить актуальные данные в том же globaldata и просто брать их оттуда для сохранения.
Если брутфорсом перебирать названия файлов на существование, не будет ли это слишком долго в случаях, когда игрок наплодил ТЫСЯЧИ ФАЙЛОВ?
Если внутри игры хранить счётчик, получится перезапись существующих файлов.
Можно ли кроссплатформенно получать от системы уникальное имя файла и юзать его как сейв?
Ну да, тоже думал об этом. Только в довесок ко времени ещё имя игрока: Player1_20200216_203145.sav перезапись файлов будет только если игрок начнёт бешено спамить кнопку сохранения. Впрочем, его пыл можно ограничить таймером в пару секунд, а можно и не ограничивать.
Это зависит от настроек шынды. Годот, как типичное кроссплатформенное приложение, имеет модуль ОС, который в хостовой системе использует её хостовые функции, в случае с виндой - винАПИ, которые могут возвращать совершенно разные результаты в зависимости от настроек. Очевидно, что модуль спроектирован под дефолтную винду с настройками искаропки и не учитывает, что какой-то ZVER в реестре отключил длинные имена в путях файлов.
https://youtu.be/twodQHm0gxw
Тоже думаю, но денег нет на хороший микрофон, а имеющиеся микрофоны в гарнитурах записывают говняно.
Из идей: Курс по скриптам для продвинутых (типизация, оптимизация, бенчмарки, обзоры и применение скриптовых ассетов и аддонов, конпеляция с дополнительными модулями самого редактора и экспортных шаблонов). Курс по архитектуре игор (как что называть, в какие папки что складывать, как организовать главное меню, как грузить локации в игровой мир, как сохранять прогресс, по чекпоинтам, по квиксейвам, как организовывать хранение файлов сохранений, как настраивать звук в игре, чтобы фон играл отдельно и плавно переключался на экшн-саундрек в схватках с врагами). Курс по тридэ (как организовать эргономичное передвижение по лестницам, чтобы игрок видел перед собой свои руки, перехватывающие перекладины лестницы и мог в случае чего остановиться, достать ствол и отстреливаться от вражин, сюда же механики падения при ранении и отстреливании врагов лёжа, реализованное в популярных шутанах, комбинированный 1/3person контроллер с плавным масштабированием камеры и переключением плеча, реализация режимов ходьбы, ползанья, полётов (левитации и на крыле), распознавание стен, ступеней, потолков рейкастами и зонами, и адекватная реакция коллиженшейпа на них, реализация пойнт и клик управления в стиле РТС, передвижение по навигационному полигону и переключение с этого режима в режим WASD и много лругое).
Курс по двадэ (подробные разборы платформенных и топдаунных механик, проектирование уровней с расстановкой по ним секретов и активностей, разбор популярных подходов к реализации оных активностей, примеры реализаций каждого в гдскрипте, создание мини-игор и интеграция их в тридэ через вьюпорт-текстуру и многое другое).
Если обладаешь поставленным голосом, студийным микрофоном, можем посотрудничать. Напишу тебе планы лекций, а ты зачитаешь и выложишь. Если ты согласен с утверждением, что авторитет создаётся годами, а рушится за секунду, если готов долго и кропотливо работать чисто по фану, без отдачи, то пиши в личку, обсудим.
Добавил простенькую кнопку скипа хода и пару новых подсказок во время игры с low bot.
Теперь заблоченные другими строениями пути перерасчитываются не полностью, а частично (до заблоченной клетки), сохраняя дальнейший путь выстроенный игроком. (Теперь не будет казаться, что пути не сохраняются)
Добавлен новый спрайт ангара.
Добавлены логи, которые можно смотреть в game_menu.
Правки мелких багов и недоработок.
Это всё замечательно, ты молодец. Я не любитель подобных игор, но желаю тебе успехов. Работай над анимациями, чтобы домики красиво строились и разрушались. Чтоб кораблики красиво разлетались на обломки. Чтобы динамичное меню свистело и пердело. И музон бодрый поставь.
https://www.youtube.com/watch?v=STenRTku4GY
Спасибо за поддержку!
У меня есть геймдиз-док где расписано уже с десяток строений, вроде как даже забаланшеных на бумаге и механизм "открывания уровней/кораблей", прилепливания любых способностей к корабликам через словари. По факту внедрение одного корабля со стандартной механикой дело 5 минут и он даже будет работать в сети.
Но вот активного рисовалы, который выдавал бы контент в виде корабликов/интерфейса включая и "за денежку" - нет (ответы вроде "не специализируюсь на космических кораблях" или проблемы с нормалмапами). Аутсорс меня отпугивает тем, что если контракт разорвется, то стиль надо будет перерисовывать заново, и я подсяду на иглу.
Так что это задерживает внедрение контента.
Чуть позже, когда на 99% отлажу/оптимизирую некоторые модули, постараюсь вкинуть сюда/гит/ассеты (network,логгер, класс для быстрой работы с хексами и т.п.).
Вчера затестил на игру с одного клиента на андроиде, против второго с компа. Все работает отлично. Только HTML-5 ругается.
Если кто-то знает, почему put_packet выдает 1 ошибку, поделитесь решением (FAILED = 1 — Generic error).
https://www.youtube.com/watch?v=0oQ5yignti4
Естесна, 2Д нужны.
Ну и чтобы по максимум изучить годот.
И тут возникает вопрос. А кто вообще придумал хранить это внутри проекта? Может лучше вынести модели блендера и документы фотошопа наверх, а внутрь только забрасывать экспорт из них, glb, png.
Получается .gdignore вообще не нужен?
Если все же Вас это заинтересует, и Вы вдруг пройдете, сбрасывайте сюда тактику, скриншот победы и пожелание награды в разумных пределах: (
- Подписка на новые apk для андроид, где можно поиграть по сети?
- Рублей 300 на карту?
- Занесение Вашего ника куда-нибудь?).
Всем хорошего дня и настроения!
>Анон же, в свою очередь, советует ОПу свернуться калачиком и сосать свой собственный стручок
>>644518
->
>>642666 →
>>642076 →
git fetch origin pull/35957/head:batch-2d
git cherry-pick d04cd4a
> Потестил сегодня вечером немного, результат не то чтобы впечатлил, но около x2 прироста на простейшем примере мигания клеточками дает.
> карта 40x80 клеток (тайл 8x8 пикс)
> 14 fps Debug, no batch
> 26 fps Debug, batch
> 17 fps Release, no batch
> 33 fps Release, batch
> карта 20x40 (тайл 16x16 пикс)
> 19 fps Debug, no batch
> 26 fps Debug, batch
> 23 fps Release, no batch
> 33 fps Release, batch
Чтобы пробовать треды, нужно быть программистом, а у нас в основном геймдизайнеры-директора.
> Many people think they will magically speed up your code. But just creating threads because they are cool could well slow your code down.
https://godotengine.org/qa/30262/how-to-properly-use-threads
ГЛ ЕС позиционировался как мобильная платформа, Вулкан же как полностью глобальная, иначе говоря, на пека она будет работать (и работает, что это я) без мобильных ограничений. На мобилах тоже, ибо к 2020 мобилы для мобильных игродебилов уже сравнялись по мощщи с мемными игровыми ноутбуками.
Следы от пуль, от покрышек, кровь, вино, кетчуп, вода - вот это всё. Предполагаю, что принцип, как с наложением теней?
Помогите разобраться с рейкастами. Как сделать, чтобы персонаж стрелял не из центра камеры, а из ствола оружия, при этом, ствол оружия должен при стрельбе быть направлен в точку пересечения вектора, направленного из центра камеры на цель, помеченную прицелом на камере в центре. Не могу разобраться, есть какая-то формула?
Вообще, при стрельбе рейкастом это как бы и не актуально. Но если делать ракетницу, то стрельба будет идти объектами-ракетами же. Или бластер, где стрельба будет производиться видимым лучом, повторяющим ранее произведённый прицельный рейкаст.
Ухх, лень полностью расписывать, что-то вроде такого:
Нода персонажа
-Нода оружия
--Нода кончика ствола
Таким образом они все вместе двигаются
Дальше ноде ствола делаешь look_at ( Vector3 target, Vector3 up ) или look_at_from_position ( Vector3 position, Vector3 target, Vector3 up ) - это в Spatial
Ну и рейкаст кидать от объекта кончика ствола, а не от камеры
Где я обосраля, неужели дефолтный шаблон настолько плох?
Переопределил to_string но это такая дикость, пиздец.
Под линухом тоже, но столько же весит и шаблон экспорта.
Короче, соберу свой годот, тем более там очень изи.
Я только не понима, как собрать шаблоны, исходников для них отдельных не нашел, они в дереве проекта в директории platform.
Мб он мне их при сборе движка тоже соберет, было бы заебись.
Да, это сработало! И код стал элегантнее. И при наличии левой ноды в параметрах она игнорируется, как я и хотел.
Просто отдельная сборка с флагами tools=no
https://gist.github.com/Calinou/ceb6d24b16d85bc47f9c5de9c9ae341d
Чтобы сильно уменьшить размер надо уже конкретно фичи отключать - 3d, видеокодеки. На ведре у меня сейчас 7Mb для 2d.
Впрочем если ты пытаешься сделать что то вроде dll (.so?) И пользоааться установленным в систему движком, то тут не знаю, не пробовал.
С чего проорал-то?
>>645357
> Запутался, что такое tools?
https://en.wikipedia.org/wiki/Toolset
Есть такое понятие в программистском укладе - тулсет. В него входят редакторы и средства отладки. Нынче зумеры не чтят лапти дидов и под "движком" подразумевают тулсет движка. А Хуан - олдфаг, матчасть знает. Поэтому компиляция с tools=no как раз и даёт нам чистый движок без редактора (тулсета).
С зависимостей между опциями.
Я не могу собрать tools=yes с некоторыми disable*-опциями, но при в сборкогайде написано, что я всего должен пересобирать шаблоны, если пересобираю двигло.
Т.е. мутные возможности таковы, как я понял:
- собрать эдитор и шаблоны, но не вырубить некоторые опции у шаблонов.
Следствие - минимальные шаблоны.
Еще я не могу target=release сделать, тому шо для шаблонов можно debug или release_debug. Но я могу собрать tools=yes target=release_debug debug_symbols=no на деле похуй, стрипну
В
- собрать отдельно с tools=no, без 3д, отключается всё, а потом пытаться собрать эдитор с tools=yes, убирая disablы, пока не соберется. Вопрос в совместимости остается открытым, хотя это один продукт.
И еще хотелось бы хотя бы один комментарий в коде модулей увидеть, я молчу про их краткое описание.
> Вопрос в совместимости остается открытым, хотя это один продукт.
Ты собираешь минимальный шаблон, в котором есть только те классы, которые ты экстендил скриптами своего проекта. А в редакторе нет смысла отключать модули. Потом запускаешь свой проект на дебаг-шаблоне и проверяешь, если какая хуйня - он в консоль напишет, чего ему не хватило. Пересобираешь или исключаешь из проекта. Когда всё работает, запускаешь на релизном шаблоне. Если всё норм - релизишь. Если не норм - ещё раз всё перепроверяешь.
Редактор пересобирать есть смысл только если ты добавляешь модули третьей стороны. Тогда да, они должны быть и в тулзовой сборке и в сборке-шаблоне.
>>645382
Разобрался, но не совсем.
Понял, что если скормить в виде шаблонов релиз и дебаг мой собранный релиз (т.е. один и тот же), то все будет норм.
Но я не понимаю, зачем ему при экспорте пути к двум шаблонам, как он выбирает нужный, зачем он вообще их сравнивает. Т.е. как мне, допустим, попросить релизный только или только отладочный юзать?
Код теперь выглядит так. Я убрал все велосипеды и задействовал встроенный механизм из ветки Control. Обошлось без самодельных классов вообще. Однако о циклический вызов таки споткнулся. Мне надо как-то ограничить перебор ссылочных списков по направлениям, но перебранные мною способы не помогают этого добиться. Вводил флаги. Добавлял состояния. Ничего не помогает. Либо не работает перебор, либо при циклическом вызове флаги сами меняются и происходит опять переполнение стека.
Примерное развитие моей мысли таково:
1. Как-то отделить первый вызванный свичер от остальных.
2. В первом обработчике отдать команду во все 4 направления.
3. В остальных обработчиках отдавать направления только в противоположном направлении от триггернувшего.
Пазл из взаимосвязанных ключей, которые могут переключаться группами и по отдельности. Распространённая штука во множестве игор. Интересно решить именно так, через ссылочный список из соседних элементов. Если ничего не выйдет сделаю по старинке - массивом и набором правил.
сделай два метода - просто переключение и переключение по нажатию. То что по нажатию - вызывает простое переключение как у нажатого так и у соседей. Метод простого переключения ничего не знает о соседях.. и замени pressed = !pressed на вызов метода
просто есть вероятность что при такой манипуляции годо генерит сигнал и у тебя по нажатию преключаются соседи, которые начинают переключать соседей и так до бесконечности..
УМВР. Внимательно доустанови чего не хватает.
Также рекомендую научиться гуглить https://github.com/godotengine/godot/issues/19060
У нас тред не совсем тред техподдержки, скорее тред обмена опытом.
Просто задавая такие вопросы здесь, отдавай себе отчёт, что в треде может не быть людей, способных ответить оперативно, день или два. За это время можно горы сайтов в гугле перелопатить. Ну и инглиш. Даже не пытайся вкатываться в геймдев без минимального знания.
Я для себя наметил такие наметки:
1. Основой сцены является т.н. distant land - огромный низкополигональный террейн 8х8 километров (8Кх8К движковых юнитов) с мыльнейшей текстурой травы и гор, без нормалмапы. По этому террейну расставлены низкополигональные деревья, горы, камни.
2. Вся эта структура видна только издалека, при приближении к любой её части она будет заполняться автоподгружаемыми чанками с высоким левелом детализации.
3. Каждый чанк имеет фиксированный размер. Он имеет в себе скрипты и всё интерактивное наполнение. И здесь главный вопрос, как лучше построить политику компоновки:
3.1. Как в ГТА - Чанки имеют размер 1х1 юнит (метр), грузятся быстро целыми пачками по мере приближения к ним, причём, когда ты быстро летишь на машине, они пропускаются из загрузки, что экономит ресурсы пеки.
3.2. Как в Скайриме - Чанки (ячейки) это логически цельные локации разных размеров. Интерьерные локации грузятся путём предзагрузки через загрузочный экран. Экстерьерные подгружаются автоматически при приближении и внимательный игрок может поймать их на этом, когда горы поблизости резко обрастают деталями.
4. Динамические объекты живут как формулы мировой логики (логики игрового мира) и наполняются телами в виде моделей при приближении игрока. Материализовавшиеся модели получают от мировой логики инфу, что они делают в данный момент, на этапе материализации. Чтоб ранее убитые враги не падали замертво на глазах кекающего от такой хуйни игрока, а чтоб материализовывались сразу мёртвыми.
Дополняйте поправляйте. И примерчиками кода порадуйте.
Сделол. Было сложно, но я нагородил велосипед из байтоёбства вперемешку со строкоёбством.
Только я сделал несколько иначе. Я в упор не нашёл в документации корректно работающего поля у потомков Control отвечающего за хранение состояния "нажатости". Фокус контролы самовольно передают друг другу. Состояние графической "продавленности" тоже передают. Поэтому пришлось добавить в метаданные кнопкам велосипедное поле, хранящее всё что мне нужно - набор флагов направлений. После чего пришлось подписать все кнопки не на один сигнал, а на целых три: button_down задаёт флаг из всех направлений, button_up снимает все флаги, pressed работает исходя из флага в данный момент, если флагов нет - ничего не делает, если флаги все - обходит всех имеющихся соседей, соседям слева устанавливает флаг "влево", справа - вправо, сверху - вверх, снизу - вниз, если есть только определенный набор флагов, обходит только эти указанные направления. Таким образом я исключил циклический вызов и кодом в 90 строк делаю то же самое, что на массиве я же сделал за 30 строк. Но теперь, оперируя простановкой соседей контролам, я могу гибко менять правила обхода контролов. Что для варианта с массивом потребовало бы другого велосипеда с правилами обхода.
> и замени pressed = !pressed на вызов метода
> просто есть вероятность что при такой манипуляции годо генерит сигнал и у тебя по нажатию преключаются соседи
Не, мне того и надо, чтобы присвоением значения дёргались сигналы.
Код вдогонку. Может кому интересно будет.
Мелкие пояснения:
1. Учусь работать с битовыми масками. Пора бы уж. 2020 год! Число & Маска == Маска - возвратит тру, если в числе есть указанные в маске биты.
2. Очень удобно константы направлений пошли как ключи для словаря соседей (nb).
3. Принцип метаданных оказался очень удобен для расширения функционала объектов. Даже наследование не нужно. Но насколько это отличается по скорости от поиска метода в классе?
Хех. Запостил код и сразу же обнаружил критическую ошибку. При простом задании правил обработки соседей будет обработан только первый обнаруженный сосед. Так как иф со всеми элифами - это один оператор. Быстрофикс.
Таки да. Код ужался вот так:
Вообще я хочу освоить "нейтивскрипт" - традиционные динамические библиотеки. Но ниасиливаю. Раньше, в дельфи это как-то всё намного проще было.
А так для меня этот вариант самый удобный. Движок пересобирать не надо. Пересобираешь только библиотеки свои. Распространяешь вместе с конечной игрой.
Построение маршрута одной функцией!
https://www.youtube.com/watch?v=KU1PslMiZ98
(Автор этого поста был предупрежден.)
https://youtu.be/azH4LD6lMpo
https://www.youtube.com/watch?v=mAbG8Oi-SvQ
Чел, ну пять секунд в гугле же, ёпта!
https://www.gamedesigning.org/engines/unity-vs-godot/
...идите это сообщение/этот пост...
https://www.youtube.com/watch?v=fZ6bOERw03M
Нелехко игоры кодировать!
Как импортировать GLTF2/0 в MeshInstance?
Бля буду, баг нашёл. При открытом микшере громкости на переднем плане фпс в редакторе отпускается до 10 кадров в секунду на 1080Ti.
https://youtu.be/vVe_DsiWNOI
> вроде как исправляет эту проблему
Эта проблема исправлена версией 3.2, заслуги мобилкодела-скамера здесь нет.
Как правильно настроить вес rigidbody?
У меня предмет одинаково легкий при весе 300 и 30000
Вообще, как сказать. Я делаю прямо на канве func _draw(): draw_circle(Vector2.ZERO, diameter, color) технически это создаёт спрайт внутри движка. На моём уровне спрайта нет, а кинематик-пулька рисует сама себя.
>>650212
Одинаково лёгкие они у тебя, когда их кинематик-персонаж толкает, да? Внимательно изучи документацию по move_and_slide. Там есть один интересный параметр по умолчанию: бесконечная инерция.
Тут даже не в спрайтах дело, я упёрся в производительность на количестве объектов. Даже если у них нет визуала, они всё равно просаживают фпс.
Про мультимешь знаю. Но мне-то не только визуал нужен, а детект коллизий. Сейчас пытаюсь реализовать такую логику:
Есть спавнер пуль. Он создаёт вокруг себя Area2D, которая детектирует координаты тел, находящихся в ней. Далее частицы летят, спавнер проверяет совпадение координат детектированных тел и пулек. Таким образом пульки отрисовываются одной функцией и для них не нужны тысячи объектов. Будем посмотреть, что получится.
И действительно. Накладывающиеся друг на друга эреи создают пикрелейтед. Пойду изучать формулу.
Расстояние между двумя точками равно диагонали треугольника на координатной сетке (одна сторона это разница координат по x, вторая по y)
Это расстояние сравнивают с радиусом (или суммой радиусов если у тебя игрок тоже круг, а не точка)
Очевидно, что если расстояние меньше радиуса, то круги пересекаются.
Формула диагонали d = sqrt(a2+b2) по теореме Пифагора
Мы проверяем d < r
Но поскольку корень дорогая операция, в движках оперируют squared значениями
d2 < r2
Таким образом в левой части просто не извлекают корень, а в правой, если возможно, используют константу. Например, если размер пули не меняется.
Ну дак! Яж и ностальгирую таким образом по старым добрым временам. Отыскиваю вот такие пасхалки от Хуана, который тоже их заложил, ностальгируя по старым временам.
>>650247
Ну дак! Либо стул с инерцией, либо стул с коллизиями. Любое упрощение в главном является усложнением в мелочах. Кинематик боди с его простыми функциями движения означает, что всю физику тебе придётся запиливать самому.
>>650248
Слава Хуану, скваред предусмотрительно вынесен в интерфейс и выполняется в скомпилированных потрохах движка на си++.
Проще всё заново переписать.
И главное, все мы знаем знаменитую пословицу, что когда возвращаешься к коду, который написан давно, то ничего не понятно. Мне-то понятно, как там и что. Но оно так мудацки написано, что у меня фейспалм с прошлогоднего себя. Например, была задача с компоновкой графического интерфейса. Я нахуярил CanvasLayer в который положил несколько Control, пикрелейтед. Потом прилепил к нему скрипт и в нём хуярил логику для всех ветвей этой сцены. Потом я сделал ветви отдельными сценами, но скрипт переделывать мне было лень и я продолжил хуярить говнокод туда. Результат немного предсказуем - глючная каша.
Сейчас сижу, сдерживая дым из горящего пердака копипащу в отдельные скрипты подсцен фрагменты оригинального скрипта, чтобы инкапсулировать поведение каждой субсцены.
Ткните носом в АПИ, если есть, пока я не написал ещё сотню строк кода.
А используется это вот так:
Как будто на 20 лет назад вернулся, во времена старого доброго дельфи!
Двоеточие-равно сильно добавляет атмосферы.
https://www.youtube.com/watch?v=QftpPI5iYrY
Пикрелейтед. Взято отсюда: https://youtu.be/4xMaq-qVQGY?t=421
Есть какой-то способ, как ускорить/оптимизировать сам Godot? У меня даже на зионе с 8 гб оперативы он умудряется тормозить. Сомневаюсь, что можно делать что-то сложнее хеллоуворлда с такими лагами. Я, конечно, понимаю, что движок целиком в одном exe под 50 метров, вряд ли из него что-то можно выкинуть, но ведь исходники открытые, должен быть способ перекомпилировать в облегченном режиме...
А ещё бы интерфейс по-проще, вместо "а-ля Блендер", но это неосуществимые мечты
Ничо не тормозит на вот таком конфиге.
Пиши конкретику, тут вообще не ясно что именно у тебя тормозит. У меня на двух ядрах и 4 гб не тормозит, если не использовать еба постпроцессинг. Какая у тебя видеокарта? Возможно в ней затык.
У меня была история с тормозами когда я добавил ноду с ошибкой. Не помню, в чем там была причина, то ли моделька была неправильная, то ли скрипт, в результате в лог сыпалось много ошибок, и из за этого сцена запускалась в 10 раз дольше. После удаления ноды и добавления заново все исправилось.
Нет. Мне надо взять кусок экрана и размазать его со всеми элементами на нем. Но мне выдает ошибку буфера. Я ставлю copybuffer снизу, но мне все равно выдает ошибку и в игре все что было с шейдером черное. Я так понял из-за вечного шейдерного цикла. Чертов SCREEN_TEXTURE;
Что ж, пришло время задавать очень глупые вопросы.
Статус: Новичок.
Что за управление в Godot ?
ПКМ - Вращение сцены. А Как двигаться ?
Управление в 3д редакторе:
Пр. кнопка мыши - вращать камерой
Ср. кнопка мыши - вращать вокруг выбранного объекта
Шифт + Ср. кнопка мыши - перетаскивание камеры редактора
Пр. кнопка мыши + WASD - движение как в шутере
Shift+F вкл/ввкл режим WASD
F - навести камеру на выбранный объект.
Что лучше выбрать, Годот или Гейммейкер?
Точно знаю, что гейммейкер подойдёт, ведь оригинал на нём и сделан, но это вроде очень ограниченный движок, а Годот позиционируется как что-то уровня Юнити, но без тормозов.
Может ли Годот в такое 2Д и есть ли тут какие-то подводные камни?
Просо если изучать с 0, то лучше уж что-то более продвинутое и мощное.
Не срача ради. Не надо сравнивать движки, просто ответе на вопрос, будет ли для этой цели Годот таким же подходящим как гейммейкер и есть ли у него какие-то плюсы в этом плане?
>Годот позиционируется как что-то уровня Юнити, но без тормозов.
Кем? Где?
>Не срача ради. Не надо сравнивать движки, просто ответе на вопрос, будет ли для этой цели Годот таким же подходящим как гейммейкер
Да, конечно.
>Может ли Годот в такое 2Д и есть ли тут какие-то подводные камни?
Есть, кое что придется оптимизировать самому.
Если заморачиваться то 6 MB.
Вот мой батник сборки
call d:\python36\Scripts\scons.bat p=android -j2 verbose=true tools=no target=release_debug ndk_platform=android-21 optimize=speed tools=no use_lto=no deprecated=no xaudio2=no disable_3d=yes disable_advanced_gui=yes no_editor_splash=yes builtin_bullet=no builtin_certs=no builtin_enet=no builtin_libtheora=no builtin_libvorbis=no builtin_libvpx=no builtin_libwebp=no builtin_libwebsockets=no builtin_mbedtls=no builtin_miniupnpc=no builtin_opus=no builtin_pcre2=no builtin_recast=no builtin_squish=no builtin_thekla_atlas=no builtin_xatlas=no debug_symbols=no separate_debug_symbols=no android_stl=no module_bmp_enabled=no module_bullet_enabled=no module_csg_enabled=no module_cvtt_enabled=no module_dds_enabled=no module_enet_enabled=no module_etc_enabled=no module_gdnative_enabled=no module_gridmap_enabled=no module_hdr_enabled=no module_jpg_enabled=no module_mbedtls_enabled=no module_mobile_vr_enabled=no module_mono_enabled=no module_opensimplex_enabled=no module_opus_enabled=no module_pvr_enabled=no module_recast_enabled=no module_regex_enabled=no module_squish_enabled=no module_stb_vorbis_enabled=no module_svg_enabled=no module_tga_enabled=no module_thekla_unwrap_enabled=no module_theora_enabled=no module_tinyexr_enabled=no module_upnp_enabled=no module_visual_script_enabled=no module_vorbis_enabled=no module_webm_enabled=no module_webp_enabled=no module_websocket_enabled=no module_xatlas_unwrap_enabled=no config=force
Плюс до сборки у меня накатываются
git fetch origin pull/35957/head:batch-2d
git cherry-pick --strategy-option=theirs d04cd4a
git fetch origin pull/36065/head:camera2d_helper_editor_only
git cherry-pick --strategy-option=theirs 69603e2
Плюс можно руками выкинуть GodotPaymentV3.java если не пользуешься.
>так делал дефолтную под две
Это удваивает размер сходу. А в плеймаркете, вроде, можно по отдельности заливать апк под каждую архитектуру.
>это надо движок пересобрать сам?
Да.
Вот эта галочка, возможно если ты ее уберешь, тебе этого хватит.
>Area можно использовать как зону-триггер?
Да, можно. Она посылает сигналы, если в нее вошла/вышла другая зона, вошло/вышло Kinematic/Rigid/Static Body. Можно вручную вызывать функции, которые перечисляют с какими area или body есть пересечение. Еще там можно задавать свою гравитацию и параметры звука, но с этим я пока не знаком.
>Jul 22, 2018
>...
>Future
>New instructions for typed code to allow faster execution. This includes avoiding the Variant evaluator and using typed arrays as well.
Я так и не понял, есть в Годо типизированные массивы или нет?
Если есть, как они правильно объявляются? Без типа у меня так:
>export var collection = []
Но тогда при задании значений массива через GUI приходится для каждой (!) ячейки указывать тип из большого списка типов. Я задолбался даже с 6-ю ячейками. Есть какой-то способ указать редактору, что я планирую заполнять массив данными одного типа?
И какой извращенец придумал хранить в массивах variant'ы? Это же противоречит самой сути массива, предназначение которого - однородные данные...
Сам спросил @ сам ответил:
>Type hints can't be used with arrays. The Array container in Godot is a variant container. If you have a particular need for a single-typed array, there are the Pool*Array types.
https://godotengine.org/qa/43783/static-typing-of-arrays-syntax
Короче, всё через жопу. Ну, хотя бы для строк есть PoolStringArray, и то ладно...
>в 4.0 что-то переделают
Чорт, опять новая мажорная версия?
Помнится, когда я щупал 2.x, узнал, что скоро будет 3.0, в которой много чего поменяют, и в итоге забил на Годо более чем на год, ожидая выхода этой самой 3.0, чтобы не углубляться в заведомо устаревшую версию...
>всякие Pool*Array тоже заменят на другое
Хорошо бы сделали как в Pascal:
var A: array [n .. m] of String; // массив с фиксированными границами
var A: array of String; // динамический массив, можно изменять длину
Вот именно второй вариант я ожидал больше всего.
Если в GDScript есть Variant, то имеющиеся сейчас массивы должны описываться так:
var A: array of Variant
Можно было сделать этот тип массива типом по умолчанию, но уж точно не делать его единственным. -_-
>ГДскрипт и есть потомок луа.
Ещё я такие пустышки использую как точки спавна, и меня беспокоит, должен ли я заменять эту точку на то, что спавнится, или пусть дальше висит... Удобно просто делать сцену дочерней от точки спавна, но я подозреваю, что с большим числом моделей это может сильно повлиять на производительность. Нет?
Вообще, сколько всего объектов (не полигонов, а вот этих сущностей) может держать Godot без просадок производительности?
> Как движок относится к большому числу таких пустышек?
Хуёво. Я десятком постов выше экспериментировал с буллетхеллом. Так вот там, если просто спавнить пустышки и добавлять их в дерево, то где-то на 5к штук начинает падать фпс. Экспоненциально. Я там отписался, что из-за спавна Area фпс падает, но потом заменил Area на пустышку, охуел и не стал ничего сообщать.
>где-то на 5к штук начинает падать фпс
Ну, это было ожидаемо. Ладно, от части Spatial я могу избавиться (хотя всё равно не ясно, можно ли как-то иначе изменять origin без плясок с бубном). Тогда следующий вопрос: возможно ли "выключать" отдельные ноды из общего дерева, чтобы они временно не тормозили игровой цикл, пока не потребуются? Собирался грубо кодом разрывать связь между предком и потомком, сохраняя потомка в отдельной переменной, чтобы потом возвращать когда понадобится, но мне на глаза постоянно попадается вот эта вкладка "Pause", и мне любопытно. Пауза ведь именно для такой заморозки объектов, которая мне нужна? Или она для чего-то другого? Если я поставлю на паузу дерево из, скажем, сотни веток - они все будут исключены из общего цикла, или будет что-то вроде if not entity.paused then entity.process else continue? В первом случае выигрыш примерно как в моём варианте, во втором всё равно каждый кадр будут лишние операции.
Лоол, есть даже готовый модуль для 3.2
https://github.com/perbone/luascript
> возможно ли "выключать" отдельные ноды из общего дерева, чтобы они временно не тормозили игровой цикл, пока не потребуются?
Возможно. Буквально в прошлом треде и начале этого обсуждали такой трюк:
1. Делаешь ноду, не включенную в общее дерево. Она висит в памяти в спящем режиме, у неё и всех её потомков не вызываются колбэки и т.п.
2. Ноды, которые надо выключить, перекидываешь в потомки этой ноды.
3. Ноды, которые надо включить, возвращаешь на свои места в дереве.
4. С помощью этой нехитрой системы можно организовать пул для динамической подгрузки чанков локаций.
О, ну почти именно так я и планировал. Только хотел извлекать одну ноду в переменную целиком, а не поштучно закидывать.
>можно организовать пул для динамической подгрузки чанков локаций
Хм, я это задумывал для подгрузки комнат в домах. Подходишь и открываешь дверь - комната появляется, закрываешь (снаружи) и отходишь - внутренности пропадают. А вот над чанками надо подумоть)
Так а для чего режим паузы нодов? Погуглил, жалуются, что паузить можно только всё дерево целиком...
Короч, если кому-то интересно, я немного поэкспериментировал и пришёл к таким выводам:
- отключение нод работает именно так, как я думал;
- подключение и отключение статикбади происходит мгновенно;
- подключение и отключение динамикбади вызывает фриз игры на секунду.
Похоже, что дело не в количестве нод, а в наличии подвижных объектов. В частности, пробовал наполнять жёлтую комнату как статичными, так и динамичными объектами (те же точки, то же количество) - статичные появляются мгновенно, динамические при появлении и исчезновении вызывают очень неприятную задержку, но после появления ведут себя как обычно (не тормозят).
Ещё заметил момент, важный конкретно для моей игры - если предмет выкатывается из комнаты, он по-прежнему остаётся привязанным к "исчезающим". То есть для игрока предмет на улице, но выходя на улицу предмет исчезает, таким образом становится недосягаемым. Знаю, как это можно исправить, да. Но вот от лага при добавлении/удалении хотелось бы избавиться. Я был бы согласен, если бы объекты появлялись постепенно, если б не вызывали лаг... А, ну, можно попробовать добавлять/удалять не в цикле for, а в _(physics)_process, но сомневаюсь, что получится норм.
Пока что Godot превосходит мои ожидания :D
Думой над архитектурой.
Допустим по сюжету игры планируется появление и исчезновение объектов. Значит ты их все грузишь при загрузке локации, затем те, которых нет для игрока делаешь невидимыми/отключёнными в большом невидимом сундуке под землёй (привет, скайрим).
> Знаю, как это можно исправить, да.
Полагаю ты про parents и owners говоришь сейчас? Если так, то сомнительно использовать механизм овнеров для динамической передачи нод между нодами. Возможно наткнуться на трудноотлавливаемые баги.
Я бы посоветовал делать одну общую ноду для "пропсов", которая по запросу игровой логики выдаёт из своего пула заранее загруженных объектов нужные локациям. Так ты избежишь проблем с
> если предмет выкатывается из комнаты, он по-прежнему остаётся привязанным к "исчезающим"
Чтобы была возможность дизайнить расположение объектов в редакторе, делай объекты-пустышки, которые уничтожают сами себя при загрузке сцены, а на их места ставятся реальные объекты из общей ноды, описанной выше.
Как-то так.
>подключение и отключение динамикбади вызывает фриз игры на секунду.
Короче, я ошибся. DynamicBody вообще не имел отношения к этим фризам.
Лень писать, опишу ситуацию кратко:
- динамические кубики CSGBox лагов не вызывали;
- сферы на скриншоте - CSGSphere с параметрами 24x12;
- снижение CSGSphere 24x12 -> 8x4 снизило нагрузку/лаги;
- 64 головы Suzanne из Blender (по 507 вершин) не тормозят.
Вывод - CSG перед появлением в дереве производит какую-то ресурсоёмкую операцию (пытается произвести слияние, даже если не с кем?), и именно она вызывает тормоза. После удаления из дерева тоже происходит какая-то операция, и снова тормоза. Всё остальное время лагов нет - меш, видимо, кэшируется. С обычными мешами такого нет.
Короче, короче... С одной стороны обидно, что так долго мучился, с другой - рад, что Годо на самом деле не такой тормоз, как я думал изначально. Теперь можно избавиться от мартышек продолжить маяться дурью делать игру.
>>652005
>Значит ты их все грузишь при загрузке локации
Именно так и делаю.
>отключёнными в большом невидимом сундуке под землёй
Так не пойдёт, Годо работает не так, хранить нужно отдельно от дерева сцены.
Точнее нужно хранить ссылку на вырезанную из общего дерева ветку в отдельной переменной.
>Полагаю ты про parents и owners говоришь сейчас?
Не знаю про owners, но я хотел передавать объект из одной ветки в другую.
>одну общую ноду для "пропсов", которая по запросу игровой логики выдаёт из своего пула заранее загруженных объектов нужные локациям
Несколько раз перечитывал, много думал, но ничего не понял. Грубо говоря, мне нужно передать ветку "предмет" из ноды "квартира" в ноду "улица", потому что нода "квартира" скрывает своё содержимое, когда игрок выходит за пределы квартиры (в целях оптимизации дерева сцены, разумеется). Если так не сделать, то "предмет" исчезнет прямо в руках игрока, когда он перешагнёт порог квартиры/закроет дверь в квартиру снаружи.
>дизайнить расположение объектов в редакторе, делай объекты-пустышки
Я так и сделал, но у меня эти пустышки нужны для спавна рандомных предметов (запилил универсальный скрипт).
>реальные объекты из общей ноды
Эм, а зачем их хранить в общей ноде? У меня они сразу появляются на точках спавна. Когда не нужны - скрываются во внутреннюю переменную скрывающей ноды (все сразу). Проблема в том, что делать общую ноду на всю сцену нерационально, у меня сейчас по сути каждая комната занимается скрытием/отображением предметов (генерация только при запуске сцены).
Вот, для примера, на скриншоте с мартышками 3.7К нод - это улица с многоэтажками, а 12.5К нод-сирот - это внутренности тех комнат, в которых игрока сейчас нет (поэтому они скрыты). Если выйти из комнаты с мартышками, они все будут скрыты. Комната сама принимает решение, когда скрывать (с помощью Area), и сама же хранит все свои внутренности. В данный момент всё это выглядит превосходно, проблема только в том, что предметы комнаты нельзя вынести за пределы комнаты. Хотя, я думаю, можно использовать ту же Area, что следит за игроком, чтобы "выпускать" предметы за пределы комнаты...
Вообще, мне главное придерживаться модульного дизайна, чтобы каждый элемент сцены был максимально независим от других. Иначе не получится так легко собирать рандомную сцену (хотя над алгоритмом сборки я всё ещё думаю). Поэтому, например, каждая комната, являясь отдельным модулем, сама заботится о генерации, отображении и скрытии находящихся в ней предметов. Такую систему легко масштабировать... контролировать, правда, трудно, но с этим я ещё разберусь.
> Не знаю про owners, но я хотел передавать объект из одной ветки в другую.
Так узнай. https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-property-owner
Это часть механизма загрузки сцен. Её нельзя игнорировать, ибо при сохранении овнера твои ноды выгрузятся со своим овнером, даже если будут у другого парента. А может и не выгрузятся. А может и не сразу, но выгрузятся. В общем - всё проверяй.
> Эм, а зачем их хранить в общей ноде?
> спавна рандомных предметов (запилил универсальный скрипт)
Скрипт наследуется от Node? Вот-вот. По факту общая нода для объектов у тебя уже есть. Только она их не хранит, а спавнит. А теоретически эффективнее делать так: Если объект стал не нужен игроку и скрывается с его глаз, он не уничтожается, а возвращается в пул, где был создан и там, в "большом невидимом сундуке" лежит до тех пор, пока снова не понадобится игроку, после чего ему скрипт-менеджер пула, который нода, назначает новое имя, задаёт новые координаты и закладывает игроку в руки.
Не происходит дорогой операции выделения памяти в куче для нового объекта.
Не происходит дорогой операции выгрузки мусора сборщиком мусора.
Происходят относительно дешёвые операции по изменению координат объектов в пространстве (физический движок) и, возможно их видимости (графический движок).
> главное придерживаться модульного дизайна
Решительно двачую!
>Это часть механизма загрузки сцен
А, ну про это я уже читал: https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
Просто речь шла про передачу от родителя к родителю, а owner только к сохранению относится.
>Если объект стал не нужен игроку и скрывается с его глаз, он не уничтожается, а возвращается в пул
Ты, наверное, про что-то другое говоришь. У меня объект не уничтожается, а временно скрывается.
>относительно дешёвые операции по изменению координат объектов и их видимости
Я бы не сказал, что это дешёвые операции, я попытался расширить зону действия Area комнат на улицу, и заметил, что если игрок триггерит сразу несколько домов по два этажа, происходит небольшой лаг. Хотя, возможно, это опять из-за CSG, только теперь виноваты лестницы (каждая ступенька - CSGBox). Кстати, заодно протестировал удаление/вставку не всей ветки, а по одной ноде за тик физического движка - стало ещё хуже, но скорее всего это из-за CSGBox. Я понимаю, что по-хорошему нужно обычные меши вставить и уже на них тестировать, но т.к. это только тест - мне лень.
Чтобы было понятнее, вот скриншоты моего кода:
1 - "генератор" (заполняет точки спавна рандомными предметами);
2 - "оптимизатор интерьера" (переписывал несколько раз уже);
3 - "глобальный RNG" (хотелось упростить выбор из списка);
4 - "менеджер ресурсов" (должен ускорять генерацию, но сомневаюсь).
Есть некоторые недочёты, но это тест, а не финальная версия)
В конце концов, там есть простые графические примитивы мешей. Они наверняка будут пошустрее CSG.
> вот скриншоты моего кода
Я предпочитаю избавляться от сравнений строк со строками в своём коде. Впрочем, это моё, бумерское. Детская травма. Нынче я понимаю, что строки работают не медленнее числовых типов. Но, тем не менее.
>Ты настолько ленив, что не можешь открыть блендер
Да.
>Это безумие
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
>CSG tools can be used for designing all kinds of levels, such as a maze or a city; explore its limitations when designing your game.
Ну вот я и exploring их limitations, пока пытаюсь design что-то вроде city.
Вообще всё началось с "а потянет ли Годо что-то эдакое, если потянет - можно будет думоть дальше".
Потянуть вроде потянул, теперь можно думоть. (думоет)
>>652160
>Я предпочитаю избавляться от сравнений строк со строками в своём коде
Я тоже, но:
- экспортные строки ничем не заменишь (хотя надо посмотреть, есть ли функция length(string) > 0);
- я без понятия, чем отличаются body, кроме name, чтобы понять, которая из них Player;
- загрузка ресурсов идёт по адресу, адрес ничем другим не заменишь.
Я лично сомневаюсь только на счёт name == "Player", но альтернативы пока не вижу (не создавать же отдельный метод it_is_player() и проверять его наличие через has_method()?), да и это сравнение по идее должно тормозить только если в сцене существует множество объектов, чьё имя начинается на "Play...". Если строка начинается с любой буквы кроме "P", она заведомо не равна "Player", и может быть пропущена. Но как именно сравнивает строки Godot - не знаю. Кроме того, эта проверка происходит только на входе/выходе объекта из Area, вряд ли она будет вызываться достаточно часто.
У меня в предыдущей версии "оптимизатора" была функция is_player_indoor, которая перебирала все объекты, с которыми пересекается Area, и вызывалась она в _ready, чтобы проверить, нужно ли скрывать интерьер сразу после запуска. Я понял, что это совершенно лишняя операция, когда попробовал безусловно скрывать интерьер - вокруг игрока он отображается, даже если игрок появляется в комнате при загрузке сцены. С другой стороны, хотелось бы создавать сразу выключенные интерьеры (так можно избавиться от лишнего добавления/удаления в сцену), но я пока не уверен, как лучше это сделать.
> не создавать же отдельный метод it_is_player() и проверять его наличие через has_method()?
Нет, конечно. Группы же есть (if body is_in_group("string_group_name") эээ, тоже строки, отпадает). Слои коллизий есть (тут соответственно уже можно либо вообще не ловить коллизии ни с кем кроме плеера, стало быть любое боди будет плеер, либо if body.get_collision_layer_bit(N) = M:). Приглашаю в документацию.
>Слои коллизий есть (тут соответственно уже можно либо вообще не ловить коллизии ни с кем кроме плеера
Аааааа, точно, точно. Я многократно натыкался на эту табличку с переключателями слоёв, но думал "ну, это мне не нужно, наверное". Было бы логично настроить детекторы только на игрока...
А вот, кстати, на счёт коллизий и лестниц. Кажется, я когда-то где-то видел, что в играх лестницы физически на самом деле не лестницы вовсе, а наклонные плоскости - в современных играх это имеет смысл или нет? А то я тут починил коллизию персонажа-игрока и вдруг появились проблемы с движением по лестницам: вверх трясёт, вниз прыгает. Если же сделать просто наклонную плоскость, то персонаж съезжает вниз. Контроллер персонажа самодельный, его нужно рефакторить, много мусора... Может, есть какие-то советы (кроме "возьми готовое")? На картинке у меня один луч определяет, находится ли игрок на земле (регулирует гравитацию и способность двигаться и прыгать), другой проверяет, не пытается ли игрок забраться на лестницу (т.к. на лестнице центральный луч зависает над землёй). Так вот движения и прыжки по плоскости и с небольшими выступами происходят нормально, но на более-менее крутой лестнице всё выглядит как-то не очень (после починки коллизии капсулы)...
А ещё я хоть и сделал камеру, которая приближается к игроку, когда с чем-то сталкивается, но она всё равно то в стены проваливается, то трясётся на углах (ну, когда луч прерывается, но не полностью). Чувствую, что ещё долго буду настраивать комфортное поведение камеры, и что делаю что-то не так( У моей камеры есть луч, растянутый между камерой и моделькой игрока, и второй луч, направленный назад. Первый луч приближает камеру, если обзор что-нибудь загораживает, второй луч предотвращает удаление камеры слишком далеко. Хотя, наверное, можно было обойтись одним лучом (надо будет попробовать отодвинуть его чуть назад)... Но вот резкие "вибрации" на углах объектов сильно напрягают. Скажем, в дверном проёме в режиме от третьего лица вообще всё начинает вибрировать, да и просто в помещениях тоже...
> в современных играх это имеет смысл или нет?
Посмотри стримы по Half-Life: Alyx и сделай выводы: Пройдёт не более полугода и классические игоры уйдут в прошлое. Вангую, к лету китайцы резко опустят ценники на виар-комплекты в ответ на возросший спрос.
А в виаре никакие жульничества не прокатят ибо игроки сразу упрутся в них и высмеют разработчика на форумах. Всё придётся делать по честному: Лестницы со ступенями. Вёдра с вогнутой коллизией. Ноги и руки с кинематикой вместо капсульной коллизии.
Будущее всегда наступает незаметно. И Габен принёс нам будущее в этом марте.
>второй луч предотвращает удаление камеры слишком далеко
А, он предотвращает отдаление камеры колёсиком мыши, если позади камеры препятствие. Без этой дополнительной проверки камеру можно было задвинуть в стену, после чего она возвращалась назад, и поэтому пришлось сделать отдельный луч (сам по себе он камеру не сдвигает). Уже забывать начал))
>>652179
>move_and_slide(... floor_max_angle
Значение по умолчанию floor_max_angle = 45 градусов. То есть оно и без дополнительных параметров должно считать лестницу полом (или потолком). Я проверил - похоже, этот параметр отвечает только за состояние функций is_on_floor и других, но у меня они всё равно не работают, поэтому я ими не пользуюсь (использую для этого лучи).
Мне, скорее всего, нужно это:
>If stop_on_slope is true, body will not slide on slopes if you include gravity in linear_velocity.
...но я проверил, и как-то не заметил особых отличий.
В общем, я подозреваю, что вся проблема либо в длине лучей, либо в логике моего кода. Сейчас смог немного отрегулировать лучи - вверх по лестнице вроде неплохо забирается, но вниз скачет. А ещё обнаружил, что в некоторых ситуациях модельку трясёт на месте (если упираться в наклонённую стенку). Скорее всего, нужно перед вызовом move_and_slide делать дополнительную проверку, но я уже устал и не хочу об этом думать сейчас.
А, вот ещё - мне хотелось добиться возможности прыгать при движении по лестнице, так вот иногда удаётся настроить возможность прыжков, а иногда настройка сбивается. Да и прыжки на лестнице почему-то получаются выше, чем на ровной земле, лол. Надо разбираться...
Скринь, хуле. Чел, я виаром уже пару лет занимаюсь. Там наоборот от реализма отходят в пользу телепортов, чтобы игроков не тошнило, к лоу поли чтобы игроков не укачивало, а та самая аликс приучает игроков что ничего не подвигать кроме того что геймдизайнер разрешил.
>ибо игроки сразу упрутся в них и высмеют разработчика на форумах
Я пытаюсь сделать игру в первую очередь для себя.
>Всё придётся делать по честному: Лестницы со ступенями
Вот, кстати, уж где-где, а в современных VR-играх смысла в лестницах нет, там ведь игрок тупо телепортируется с места на место. Передвигаться в VR вообще сложно. А ещё я не представляю, как можно играть в VR, если у тебя в комнате и без него развернуться негде...
>классические игоры уйдут в прошлое
Только когда выйдут полноценные нейрошлемы. Тот VR, который есть сейчас, по сути обычная игра, только на двух мониторах и со сложными джойстиками. Я пробовал, мне не понравилось - хочу лежать в кровати и не двигаться, пока играю в игру, которая транслируется прямо мне в мозг. Вот когда будут нейрошлемы, тогда игрокам действительно будет неохота вставать и пялиться в монитор... А сейчас всё наоборот: запустить игру намного проще, чем подготовить VR-оборудование к работе. Если бы у меня был мощный беспроблемный ноутбук, я бы вообще с кровати не вставал, какой уж там VR.
>>652189
>На любую задачу сначала гугли документацию
Так скучно. Я читаю встроенную справку, но остальное пытаюсь сначала сам сделать.
>Для контроля камеры есть нода SpringArm
Написано "для 3 лица". Мой контроллер может переключать между первым и третьим) Но спасибо, посмотрю.
>А то ты много велосипедов изобретаешь
Это у меня по жизни так. Я вообще очень долго не хотел даже пробовать готовые движки.
>>652197
>move_and_slide_with_snap
Заметил эту функцию, когда листал справку, надо будет проверить...
> а та самая аликс приучает игроков что ничего не подвигать кроме того что геймдизайнер разрешил
Теперь ты хуйню несешь, чел занимающийся виаром, виара не видавший. Не позорься, посмотри, как её стримят хоть. Ясен хуй, сам ты в неё поиграть не сможешь. Гранаты в ведре поносить не сможешь.
> 100500 других пропсов не дали
Что ж ты за отбитый долбоёб, а? Ясен хуй, сформулировать ты ответ на это не способен. Да и не видел ты, как в алихе можно ящики и бочки таскать руками. Что тебе на форумах написздели, то ты и ретранслируешь. А моменты, когда ты одной рукой лечишься в лечилке, а второй рукой держишь на прицеле угол из-за которого может комбайн выскочить - просто бесценны!
> Вот, кстати, уж где-где, а в современных VR-играх смысла в лестницах нет, там ведь игрок тупо телепортируется с места на место. Передвигаться в VR вообще сложно. А ещё я не представляю, как можно играть в VR, если у тебя в комнате и без него развернуться негде…
1. Телепорты от тошноты - мера временная, потому что гироскопы не поспевают за головой.
2. Двигаться путём прожима аналогового стика на контроллере можно уже сейчас, но из-за 1. у многих возникает морская болезнь.
3. Согласно моему вангованию, эту проблему победят уже в этом году.
4. Раз двигаться можно стиком, от тебя требуется только сидеть во вращающемся кресле.
5. Однако в этом случае ты не сможешь пригибаться и уворачиваться. Так что встал и стой, сцкнх!
6. Согласно моему вангованию, ближе к концу года, возможно в начале следующего, китайцы выкинут на рынок недорогие и функциональные беговые дорожки и в виаре можно будет вообще полноценно бегать, прыгать, перекатываться.
7. Жирные тюлени вроде нас с тобой, несомненно соснут, но рыночек порешает нас, а не зумеров.
8. Так что, да, остаётся только
> сделать игру в первую очередь для себя
Потому что корпорации, по моему вангованию, повторюсь, не позднее, чем за пару лет, ПОЛНОСТЬЮ перепрофилируются на виар.
Всё, нах, можете скринить.
>корпорации ПОЛНОСТЬЮ перепрофилируются на виар
Туда им и дорога, у меня их игры даже на диск не помещаются, не говоря уж о запуске, так что вообще без разницы, какими эти игры будут.
>Жирные тюлени вроде нас с тобой, несомненно соснут, но рыночек порешает нас, а не зумеров
Так-то принято считать, что зумеры самые малоподвижные... или миллениалы...
>в виаре можно будет вообще полноценно бегать, прыгать, перекатываться
Повторяюсь, без нейрошлема все эти забеги, прыжки и перекаты не имеют никакого смысла. Я врастаю в клавиатуру не для того, чтобы бегать-прыгать-перекатываться, а для того, чтобы не бегать, не прыгать и не перекатываться в реальном мире. Кто вообще придумал использовать тело как контроллер? Это же неудобно.
>Двигаться путём прожима аналогового стика на контроллере можно уже сейчас
Тогда чем это отличается от обычной игры? Только углом обзора как в подзорной трубе.
>Телепорты от тошноты
Всегда думал, что телепорты для того, чтобы сидеть/лежать неподвижно, а не топтаться стоя.
>>652211
>там же надо 120 фпс в 2-4К
Ну 120 фпс допустим вытянуть можно с лёгкостью, а 2-4К сделать тупо апскейлом.
Мне больше волнует, почему у меня контроллер камеры при повышении фпс до 700+ начинает замедляться. :C
Как видос записать и скинуть? Да, вопрос тупой, в инете 100000 ответов, но я не хочу среди них искать нормальный, куда проще если кто-то поделится проверенным
>откуда ей заного взятся то
я такое говно ещё в гамаке делал или в камстракте
>тень не может быть "короче" или "длиннее",
Может, зависит от высоты источника света над отбрасывающим тень объектом.
Предлагаю вернуться в 5-й класс и повторить чё вы ты там изучали про свет и тень)))
Ну или хотя бы выходи на улицу почаще, а то ты походу тени только в детстве в играх видел.
короче, есть один спрайт палки
палкой можно будет махать в игре
можно ли как-то сделать анимацию махания палкой чем-то типа создания ключевых кадров? нужно чтоб просто менялся её угол наклона
не делать же мне анимацию для палки, ну
Ну да, в годоте все свойства анимируются примерно как в блендере
1. В AnimationPlayer в анимации добавляешь новый трек, Property Track
2. В всплывшем окне выбираешь объект, а в нем свойство rotation_degrees
3. Ставишь время на 0, кликаешь правой кнопкой по таймлайну и insert keyframe
4. Ставишь время в середину, крутишь объект как тебе надо, вставляешь новый keyframe
5. Ставишь время в конец, крутишь объект в начальное положение, еще один keyframe
Тоже молчит. Выглядит, будто сцена штатно закрывается, но на самом деле это краш.
Происходит это со сценой, в которой я сделал такую штуку (вид сверху):
__с__
__д__
сдддс
__д__
__с__
Где д - блок дороги, с - точка спавна, _ - пустота.
На точке спавна должна спавниться точно такая же сцена с некоторым шансом, которая тоже что-то спавнит.
Методом тыка выяснил, что падение происходит только в определённых условиях, но определить точно эти условия не смог, потому что у меня даже print() из кода не успевает ничего вывести, когда эти условия срабатывают. Было предположение, что это происходит тогда, когда два блока накладываются друг на друга - но смещение точек спавна выше или ниже ничего не дало. Ещё было предположение, что происходит переполнение стека возвратов, но, судя по всему, в одном направлении генерироваться такая штука может достаточно долго. Пытался приделать проверку коллизий перед спавном, но они не работают в _ready, поэтому решил не мучиться. Короче, так и не понял, почему это происходит и почему без сообщений об ошибках. Версия Годо 3.2.1 stable.
Но это уже не важно, я решил отказаться от такой генерации. Нужно генерировать сначала меш ландшафта, а потом на нём расставлять домики, так должно быть правильнее...
> Тоже молчит. Выглядит, будто сцена штатно закрывается, но на самом деле это краш.
Переполнение стека вызовов функций. Ищи, где у тебя бесконечная рекурсия. У меня такое бывает частенько, если с рекурсией проебусь. Ошибка возникает на долю секунды, после чего сеанс отладки прерывается.
https://www.youtube.com/watch?v=oXQOaO8qoLo
Главное, чего я не могу понять, в редакторе у кости одна позиция - её начало. В рантайме, как видно из скрипта, позиция кости - это середина. Мне приходится отрисовывать две линии, от кости к предку, от кости к потомкам. Иначе получается вот такое:
Вот в режиме тулскрипта. Никакого масштабирования нигде не ставил, все значения по дефолту.
Проблемы:
- кинетикбоди пинает ригидбоди
- если отключить бесконечную инерцию, всё равно пинает, но только уже сдвинутые
- круглые ригидбоди катятся и не останавливаются
- сила трения непонятно на что влияет
- непонятно как влияет на физику масса объекта
До того момента, как я узнал про флаг бесконечной инерции, думал, что физика здесь упорота принципиально.
Помогла вот эта статья, но только частично: https://kidscancode.org/godot_recipes/physics/kinematic_to_rigidbody/
То есть на неподвижные ригидбоди это работает, а если что-то сдвинуто/катится - опять "пинает".
Круглые ригидбоди вообще неуправляемые, что с массой, что с трением. Катятся и катятся.
Что делать(
>круглые ригидбоди катятся и не останавливаются
За это отвечает Angular Damp в размере 0.8-1
> сила трения непонятно на что влияет
Проверил на 3д кубах - все работает, 0 трения скользит как по льду, 1 сразу останавливается или опрокидывается, 0.5 ведет себя как игральный кубик
>непонятно как влияет на физику масса объекта
Как и должна, передача импульса, все дела, тяжелый объект при столкновении сдвинет легкий, легкий объект отскочит от тяжелого.
>За это отвечает Angular Damp в размере 0.8-1
Спасибо, разобрался. У меня по умолчанию в настройках проекта 0.1 стояло. Правда, неясно, чем руководствоваться для установки того или иного значения.
>0 трения скользит как по льду, 1 сразу останавливается или опрокидывается
Да, действительно. Я просто пытался поставить 10 - у меня всё в стороны разлеталось, и я пытался увеличить силу трения. Кажется, в реале сила трения должна при определённых значениях держать объект неподвижным...
>тяжелый объект при столкновении сдвинет легкий, легкий объект отскочит от тяжелого
Так-то так (уже убедился), но пока что у меня даже тяжёлые объекты отскакивают от KinematicBody. Скажем, собранная мной машинка нормально взаимодействует, а игрок - нет. Я знаю, что проблема в move_and_slide(), но не понимаю, как это откалибровать, чтобы соответствовало массе объектов. Я и машинку могу толкать во все стороны, хотя она 4 тонны весит... Или вот назначил кубикам вес в 10 тонн, а толку? Машина об них останавливается - и это правильно - а вот игрок спокойно "пинает" эти кубы, будто это просто мячики.
Самое странное в этих пинках: если сцена только загрузилась, кубы стоят неподвижно, и если им не прописывать импульс от столкновения вручную (как в статье по ссылке выше), то они не будут реагировать на игрока (KinematicBody). Но если я с помощью машинки хотя бы немного толкну куб, то он как будто меняет своё состояние, и теперь я могу пинать его во все стороны, хотя для машины он по-прежнему слишком тяжёлый. Если полежит немного, снова отключается. Вроде бы это должно быть связано с состоянием sleeping, но почему он пинается, когда не спит, если infinite_inertia = false?
...короче, я уже перебрал весь свой PlayerControl, даже умудрился подогнать ускорения к реальным величинам, но всё равно не нашёл причину проблемы. Такое ощущение, что мне нужно написать для игрового персонажа вообще всю физику с нуля, и только для того, чтобы он прекратил пинать десятитонные кубы как мячики.
Хотел уже приделать какой-нибудь костыль, типа навесить RigidBody и пусть он взаимодействует вместо KinematicBody, но это бред какой-то. Почему решение такой обыденной задачи настолько нетривиально((
...а, я вспомнил, что могу придавать начальный импульс предмету, с которым столкнулся, ориентируясь на его массу. Ввёл условие, которое игнорирует объекты с массой больше массы игрока, добавил вычитание массы предмета из массы игрока при вычислении импульса (да, примитивно, но не знаю как правильнее) - теперь игрок пинает только лёгкие предметы, и чем легче предмет, тем дальше пинает, но... Но, блииин, по-прежнему сохраняется та фигня с "разбуженными" кубами. То есть если на 10-тонный куб наехать колесом машины, он не сдвинется, но в течении нескольких секунд игрок может его ПНУТЬ, и он покатится. При этом это никак не зависит от моего импульса, это явно физический движок что-то сам решает... Ну почему так((
Ещё заметил, что машинка тоже по сути игнорирует все мои попытки её не двигать. Если толкать перпендикулярно движению, она может сопротивляться, может вообще не обращать внимания. Но если толкнуть по направлению движения, она резко ускоряется и катится дальше, хотя двигатель, очевидно, выключен. Нет, я помню, что нужно на ручник ставить, но дело в том, что она так сильно ускоряется из-за этого дурацкого "пинка", от которого я никак не могу избавиться. Фиг с ними, с кубами, но если у меня машины так и будут отпрыгивать от игрока, это будет невыносимо( Есть подозрение, что машина так реагирует, потому что никогда не бывает в спящем состоянии, и всё время реагирует как "разбуженный куб". Но почему это всё именно так происходит - никак не пойму(
Да, движок Bullet, встроенная физика Годо на моей сцене крашится почему-то (без сообщений об ошибках, просто закрывается).
>Почему годот просаживается на 4х тысячах спрайтов одновременно двигающихся?
Попробуй посмотреть вот эти значения:
var objs = Performance.get_monitor(Performance.OBJECT_COUNT)
var nodes = Performance.get_monitor(Performance.OBJECT_NODE_COUNT)
Там наверняка больше 4к будет.
По идее, для того, что ты хочешь, можно попробовать использовать MultiMeshInstance2D:
>MultiMesh provides low-level mesh instancing. Drawing thousands of MeshInstance nodes can be slow, since each object is submitted to the GPU then drawn individually.
>MultiMesh is much faster as it can draw thousands of instances with a single draw call, resulting in less API overhead.
>As a drawback, if the instances are too far away of each other, performance may be reduced as every single instance will always rendered (they are spatially indexed as one, for the whole object).
>Since instances may have any behavior, the AABB used for visibility must be provided by the user.
>казаки держали 8 тысяч активных юнитов
Скорее всего "юниты" не были отдельными сущностями, а держались в одном массиве. То есть для смещения и рендеринга игре не нужно было далеко бегать, i+1 и всё. Это называется Data-oriented Design:
>In computing, data-oriented design is a program optimization approach motivated by efficient usage of the CPU cache, used in video game development. The approach is to focus on the data layout, separating and sorting fields according to when they are needed, and to think about transformations of data. https://en.wikipedia.org/wiki/Data-oriented_design
В той же статье есть раздел "Motives", и там как раз про эти древние 200 Гц процессоры. Как я понял, основная проблема не в процессоре, а в том, что процессор вынужден искать данные в памяти, и тратить на это много времени. Если мы используем массивы однотипных данных, они могут загружаться в кэш процессора последовательно и поэтому процессор не будет тратить время на ожидание оперативной памяти. Кэш маленький, но он вроде заранее заполняется, если процессор может предсказать следующий блок данных (ща все оптимизации ЦП строятся на том, чтобы выполнить задачу раньше, чем программа об этой задаче попросит). А в ООП-подходе данные разбросаны по памяти рандомно, и процессор вынужден искать эти данные в оперативной памяти, что тормозит всю работу.
В документации Годо по этому поводу есть вот это: https://docs.godotengine.org/en/stable/about/faq.html#why-does-godot-not-force-users-to-implement-dod-data-oriented-design
Короче, Годо ориентирован на удобство большинства игр, а большинству игр двигать тысячи спрайтов одновременно просто не нужно, поэтому Годо в своей основе использует ООП, которое не очень дружит с большим числом объектов. А для тех, кому всё-таки нужно, совет:
>If a game that really needs to process such large amount of objects is needed, our recommendation is to use C++ and GDNative for the high performance parts and GDScript (or C#) for the rest of the game.
>А то окажется, что там было разрешение 800х600, спрайты размером 16х32 и 12 фпс.
ИМХО проблема не в разрешении и размерах. Если статично расставить по 3D-сцене >15000 нод, то Годо может выдавать почти стабильные 75 фпс на 1440x900. Но если хотя бы часть этих нод подвижна, то всё сильно ухудшается. Значит, проблема именно в адресации данных, а не в их размерах. Грубо говоря процессору приходится бегать по памяти, чтобы 60 раз за секунду немножко сдвинуть каждую из тысяч сущностей - и именно здесь происходит просадка. DoD призван исправить эту проблему, но DoD через GDScript реализовать не получится, если я правильно понимаю, поэтому рекомендуется подключать внешние низкоуровневые/компилируемые ЯП.
В Годо нет ООП.
Юнити, не смотря на свои огромные монобехейворы держит 9к спрайтов без лагов.
nodes/objects - Нахуя? Я просто взял и вкинул спрайты на сцену. У меня создано 4к спрайтов, а дальше резко идет падение по производительности. Резко - это когда почти 90 градусов после превышения значения. Почему это лагает? Это просто точка с положением от которого надо рендерить изображение и если оно закрывает другое, альфомаской стирать то, которое под ним.
MultiMeshInstance2D спасибо. Посмотрю. Надеюсь мне не придется вытворять магию, чтобы просто создать несколько сотен спрайтов.
>В Годо нет ООП.
Чиво? Скрипты на GDScript - это отдельные классы, со свойствами и методами. И всё, что ты используешь в скриптах, это тоже какие-то стандартные классы движка и их методы/свойства/константы. Можно объявить свой скрипт кастомным классом (class_name) и наследоваться от него. Потом, каждая нода имеет в себе свойства и функции, чем не ООП? Внутри движка есть какие-то оптимизации, но снаружи это явное ООП.
>У меня создано 4к спрайтов, а дальше резко идет падение по производительности. Резко - это когда почти 90 градусов после превышения значения
Ограничитель FPS снят? Если снять ограничитель, будет видно, что без нагрузки Годо выдаёт сотни кадров в секунду - "резкого падения" нет, просто ограничитель по умолчанию залочен на частоту экрана (60/75 Гц), и ты видишь просадку только когда она падает ниже ограничения.
>Почему это лагает? Это просто точка с положением от которого надо рендерить изображение
Потому что
>спрайтов одновременно двигающихся
Ты же в каждом отдельном спрайте позицию меняешь? Вот. Где данные положения находятся в памяти - заранее неизвестно, процессору приходится запрашивать у оперативной памяти данные каждого спрайта.
>MultiMeshInstance2D спасибо. Посмотрю.
https://docs.godotengine.org/en/stable/tutorials/3d/vertex_animation/animating_thousands_of_fish.html#making-a-school-of-fish
Правда,
>The problem with MeshInstances is that it is expensive to update their transform array. It is great for placing many static objects around the scene. But it is still difficult to move the objects around the scene.
>To make each instance move in an interesting way we will use a Particles node. Particles take advantage of GPU acceleration by computing and setting the per-instance information in a Shader.
https://docs.godotengine.org/en/stable/tutorials/3d/vertex_animation/controlling_thousands_of_fish.html
>просто создать несколько сотен спрайтов
>несколько сотен
>создано 4к спрайтов
Так тебе несколько сотен, или несколько сотен + 4 тысячи? В FAQ же написано, большинству игр не нужны тысячи спрайтов одновременно движущихся, поэтому движок использует более простую модель (которая понятнее новичкам и дизайнерам), но если всё-таки нужны тысячи - можно запилить костыль оптимизированный код на C++/GDNative, но это уметь надо.
Но если тебя так привлекают 200 Гц доядерные процы, пили на C без каких-либо движков.
https://ru.wikipedia.org/wiki/Инкапсуляция_(программирование)
>Инкапсуляция — в информатике размещение в одном компоненте данных и методов, которые с ними работают. Также может означать скрытие внутренней реализации от других компонентов.
>...некоторые языки (например, Smalltalk, Python) реализуют инкапсуляцию в полной мере, но не предусматривают возможности скрытия в принципе.
>В общем случае в разных языках программирования термин «инкапсуляция» относится к одной или обеим одновременно следующим нотациям:
>- механизм языка, позволяющий ограничить доступ одних компонентов программы к другим;
>- языковая конструкция, позволяющая связать данные с методами, предназначенными для обработки этих данных.
GDScript подобен Python, а Python - ООП, хотя в Python нет скрытия данных.
Только давайте не устраивать срач на тему труЪ-ООП.
И вот ещё - https://godotengine.org/qa/42034/oop-in-godot
>Godot is strongly OOP. Nodes and scenes are objects, as are scripts, so you can use inheritance with either of them.
> Только давайте не устраивать срач на тему труЪ-ООП.
Точку в этом вопросе недавно поставил extremecode на youtube. Кроме того, твоя же паста говорит, что авторы питона как раз таки понимают суть, в отличие от "так же означающих".
Инкапсуляция - это не сокрытие. В гдскрипте нет скрытия, нет приватных членов. Однако там есть инкапсуляция, наследование, полиморфизм. Таким образом, я подтверждаю, что гдскрипт стронгООП.
>Надеюсь мне не придется вытворять магию
MultiMeshInstance это не то чтобы магия. Это примерно то же, что используется под капотом для частиц (particles)
Также можно смортреть в сторону вот этого пулл реквеста, в котором ведутся работы и там уже х2.5 прирост в спрайт батчинге: https://github.com/godotengine/godot/pull/37349
>чтобы просто создать несколько сотен спрайтов.
Несколько сотен спрайтов ты сможешь создать и сейчас, тест в шапке - 60 фпс на некропеке при ~1000 спрайтах.
>4300 спрайтов. Меня интересует что угодно, что достигнет хотя бы 9к. А ещё лучше 15к.
Способы выжать сколько угодно спрайтов есть. Только управлять ими ты не сможешь.
>>653372
>Я сам решу, нужны мне 9к спрайтов или нет. Спасибо.
Сразу об этом и не подумал. Серьёзно, зачем тебе 9к спрайтов на одном экране?
1920 x 1080 / 9000 = 230 пикселей на один спрайт = 10x23 один спрайт.
Это если располагать их сеточкой, то есть без пробелов.
Один вопрос: зачем?
Если тебе нужно расположить 9к спрайтов на одной сцене, а не на одном экране, то тут уже другие способы оптимизации нужны, потому что 9к спрайтов на одном экране у тебя никогда не выйдет (точнее отдалить-то камеру можно, но спрайты сожмутся в точки, кому это нужно?).
Короче, опиши вкратце, что хочешь реализовать, а мы подумаем, чем тебе можно помочь.
>>653385
>Почему apk с пустой сценой весит ДВАДЦАТЬ СРАНЫХ МЕГАБАЙТ?
Никогда не слышал выражение "библиотека с кодом"? В ней содержится всё то, благодаря чему ты можешь делать игры без головной боли, просто тыкая мышой по кнопочкам и не задумываясь о низкоуровневых проблемах конкретной ОС и/или низкоуровневых игровых алгоритмах. Хочешь пустой APK - пили на Java с нуля, только тебе придётся самому возиться с тем, с чем возятся эти 20 МБ вместо тебя.
Стоит ли вообще? Какие подводные?
>Какие подводные?
Имхо, визуально блоки добавлять и редактировать в несколько раз дольше и сложнее, чем код писать.
Если уже умеешь писать код и не имеешь с этим проблем, то лучше даже не пытаться в визуальный код.
потыкался, ниасилил, вернулся к использованию gdscript
Даже не знаю, какой дисигнер осилит визуальный скриптинг
Ну смотри, принципиальная разница между кодом и "визуальным программированием" в том, что в одном случае ты пишешь текст, который будет читать компьютер (транслятор), а во втором ты двигаешь мышу и жмёшь на виртуальные кнопки, натягиваешь виртуальные ниточки и переключаешь виртуальные переключатели, а ещё вводишь в разные поля ввода всё тот же текст, чтобы... чтобы, ВНЕЗАПНО, создать всё тот же код, который будет читать компьютер, просто у этого кода будет графическое представление (но на диск он всё равно сохраняется в виде какого-то текста).
Чтобы программировать, нужно три вещи:
- уметь составлять алгоритмы для решения задач;
- знать базовый синтаксис выбранного ЯП;
- знать содержимое используемых библиотек.
Что из этого может убрать визуальное программирование?
- алгоритмы тебе в любом случае придётся составлять;
- вместо синтаксиса тебе нужно знать GUI редактора;
- библиотеки используются те же самые, что и с кодом.
То есть визуальный кодинг всего лишь подменяет текст на ГУЙ, в который тебе нужно мышой тыкать.
Разумеется, речь о том визуальном кодинге, который есть сейчас (вообще в мире, не только в Годо), это не значит, что никогда не появится гениальное изобретение, которое отменит необходимость писать код, но пока оно не появилось, использовать визуальные инструменты банально неудобно, КПД резко снижается. Проще немного подучить ЯП, тем более GDScript достаточно прост.
>разве что со словарём
Практически ни один программист не помнит наизусть содержимое библиотек. В крупных ЯП даже необязательно знать все фичи языка, чтобы успешно писать программы. Мануал - твой друг, используй его. А в том же визуальном программировании тебе всё равно потребуется помнить все эти многочисленные блоки, их назначение и способы применения...
>ЖРПГ
Если речь о классических 2D jRPG, не проще ли будет использовать RPG Maker? Там вообще кодинга не нужно вроде.
>Если речь о классических 2D jRPG, не проще ли будет использовать RPG Maker? Там вообще кодинга не нужно вроде.
В том-то и дело, что есть задумки, которые на мейкере сделать тяжко, невозможно или ХЗВЩ как.
А по поводу подучить язык... ну, замечание верное. Попытаемся, короче.
- расторможенные RigidBody пинаются;
- автомобили пинаются вообще всегда;
- на наклонных плоскостях соскальзывает;
- на маленьких бордюрах подпрыгивает.
Последняя проблема недавно появилась, раньше как-то удавалось избегать.
Замена move_and_slide() на move_and_slide_with_snap() не помогает.
Я уже замучился, я хотел просто игру делать, а не вот это вот всё.
Смотрел чужие контроллеры, там всё аналогично...
>- расторможенные RigidBody пинаются;
>- автомобили пинаются вообще всегда;
Оооокееей, эти две проблемы я внезапно решил, случайно обнаружив параметр safe_margin, который по сути заставляет Kinetic_Body останавливаться раньше, чем Rigid_Body детектит столкновение с ним, если я правильно понимаю.
Остаётся только понять, как исправить это -
>- на наклонных плоскостях соскальзывает;
>- на маленьких бордюрах подпрыгивает.
Но это по крайней мере можно закостылить RayCast'ами, хоть я и хотел бы более простое решение...
В предыдущей версии контроллера у меня оно уже решалось как-то. Скорее всего потому, что я занулял скорость по Y, если был контакт с землёй, а тут я сделал так, как сделано в других контроллерах - вместо зануления вручную, сохраняю ответ move_and_slide(), она сама зануляет Y если персонаж ударился о поверхность. Так вот если занулять Y, то персонаж будет стоять на наклонной поверхности как на ровной, а если не занулять, то move_and_slide() будет делать микроскопические скачки, которые выглядят как скольжение. Один из аргументов должен предотвращать скольжение, но он почему-то не работает.
Я уже смотрел несколько вариантов контроллера в сети (вроде 3), они все такие разные (и при этом не учитывают такие сложные ситуации)...
Но больше всего мне непонятно сейчас, почему персонаж начал ПОДСКАКИВАТЬ на бордюрах. Раньше он либо забирался плавно, либо вообще не мог забраться, а сейчас он взлетает в воздух и приземляется на бордюр, если хватает инерции. Вроде бы это появилось после того, как я снизил сопротивление воздуха, то есть уменьшил торможение, когда нет контакта с землёй - но проблема в том, что если я увеличу это сопротивление, будет невозможно делать длинные прыжки, только прыжки на месте. Костылировать каждый такой случай рейкастами совсем не хочется... Хотя, наверное, правильнее всего будет делать "шаг вверх" при обнаружении относительно низкого препятствия, ведь в реале люди шагают, а не скользят, лол.
>Сигналы. Сигналы решают эту проблему.
Я не разобрался, по-моему биндинг сигналов какой-то мудрёный. Да и посылать сигнал практически каждый кадр?
>Либо ты должен описать вращение в персонаже, и передавать его на камеру.
Изначально так и было, но я решил абстрагировать камеру, чтобы облегчить персонажа.
В общем, всё оказалось намного проще и компактнее, см. скрин. :D
Персонаж сам себя вращает по камере, когда хочет, а камера теперь не сможет никого вращать.
>>653903
>И да, просто "шаг вверх" будет хорошим решением, ящитаю.
Пытаюсь так сделать, но чёт не выходит. Задолбался в очередной раз...
Там можно устроить месиво из пикселей, как я понимаю.
>>654240
>Поставь 7 тысяч юнитов и они без лагов дойдут куда угодно
Ты это цветное месиво называешь "7 тысяч юнитов"?
Теоретически, можно соединять все эти спрайты на процессоре, видеокарте тут нечего делать вообще.
Но, конечно, это будет проще реализовать на каком-нибудь Ассемблере, чем прикручивать к Годо или другому движку.
Движки общего назначения не подходят для создания игр не общего назначения, без жесткого допиливания напильником их недр.
Тут просто тонко настраивают отрисовку объектов, а не делают в лоб. Например, вот, на картинке 216к кубов одновременно в кадре выдают на некроноуте 30 фпс.
Так что тебе или лезть в ядро любого такого движка или накидать свое решение или прикрепить свое решение к движку в виде модуля.
> Не помню где, но где-то прочитал, что чтобы код и сцены были модульными, в коде нельзя обращаться к нодам-родителям, только к нодам-потомкам.
Глупости. Допустим, тебе нужен универсальный компонент, работающий только с кинематиками, а если ты про запарке его закинул в ноду иного класса, он должен это детектить и деактивироваться. Возможно даже с ассертом. И ты просто создаёшь переменную var body : KinematicBody и в ready пишешь такой код:
if get_parent() is KinematicBody:
body = get_parent()
else:
assert(true)
print("This component function only as KB child")
set_process(false)
И всё, у тебя универсальный компонент, с которым невозможно ошибиться. Он не даст тебе нормально работать в случае неправильного размещения в дереве.
Таким образом ты можешь внести логику движения в отдельные компоненты и переключать функционал путём динамического удаления и добавления компонентов. По земле персонаж бежит когда у него компонент walk.gd, по воде плывет, когда swim.gd, а если тебе надо переключаться между персонажами, то ты вешаешь на персонажей ai.gd
А управляет переключением компонентов разумеется стейтмашина, конечный автомат.
>Если наше ПО что-то не умеет - это потому что оно "общего назначения".
Всё абсолютно наоборот. "Общего назначения" означает, что ПО буквально умеет "всего понемножку", из всех или большинства возможных областей применения. С одной стороны это хорошо, т.к. пользователь может изучить это ПО и не искать под каждую задачу специальное ПО, но с другой стороны "ПО общего назначения" не имеет специальных оптимизаций для конкретных ситуаций. "Специализированное ПО", напротив, умеет только что-то одно, но умеет это превосходно.
В случае Годо и 7к спрайтов: Годо оптимизирован для удобного дизайна и управления сценами, ты можешь практически одной мышкой, не притрагиваясь к клавиатуре, сделать прототип своей игры, и это применимо к большинству видов игр. Если бы Годо был оптимизирован под огромное количество однотипных данных, то вместо имеющегося удобства были бы очень неудобные инструменты, которые работают быстро, но раскрывают свой потенциал только на 5к+ одинаковых объектов.
Другими словами, Годо умеет очень многое, но тебе всё это не нужно. Ты сейчас можешь взять язык Си и написать очень примитивный игровой движок, который не будет уметь всего того, что умеет Годо, но благодаря своей специализации сможет рисовать сотни тысяч спрайтов - а тебе, как я вижу, кроме этого ничего больше и не нужно.
>>654410
>Он не даст тебе нормально работать в случае неправильного размещения в дереве.
Пример - KB-платформа и KB-персонаж, скрипт swim.gd случайно цепляется на платформу, платформа уплывает.
>По земле персонаж бежит когда у него компонент walk.gd, по воде плывет, когда swim.gd
Мне кажется, или подключение/отключение компонентов в случае бега/плавания - это немного лишнее? Ведь персонаж по идее всегда умеет бегать и плавать, а не только когда находится в воде... Можно же просто добавить процедуры:
if in_water():
swim()
else:
walk()
Хотя да, так труднее будет дизайнить инвалидов))
Да и меня вот смущает, что я не могу накинуть несколько скриптов на одну ноду, мне этот swim.gd на Node-пустышку вешать что ли?
Если бы я делал компоненты, я бы сделал так:
- нода, которая ждёт компоненты, имеет в update код типа:
for component in components:
component.tick(self)
- нода, которая хочет быть компонентом, имеет метод tick(), в котором делает полезную работу;
- метод tick() принимает ноду, с которой нужно работать, получая доступ к её редактированию;
- расположение компонента и подключающей его к себе ноде не имеет значения.
Т.о. можно создать только один swim.gd, а все персонажи, которые хотят плавать, будут делать swim.tick(self).
Правда, это не решает вопроса уникальных переменных...
Вообще, в Ъ-ECS компонент swim был бы всего лишь флажком или набором переменных, означающим, что конкретную сущность нужно передать в систему плавания, которая будет плыть эту сущность так, как посчитает нужным. Но на Godot, конечно, надстраивать полноценную ECS смысла нет, я полагаю...
Есть один сетевой 3д проект для своих нужд, успел уже сделать редактор уровней (алсо записываю все уровни в свой васянский формат), но теперь думаю как оптимизировать все это.
На первой картинке: бот запрашивает маршрут от своей позиции к нужной ему, но маршрут строится напрямую через две точки. Навмеш представляет собой коробку 10x2x10, создал из простого растянутого меша-куба. Учитывая то, что сдвиг навмеша в сторону обрывает путь на краю навмеша, я полагаю, что дырка в навмеше должна вызвать построение пути в обход дырки? Но если это так, то я должен вручную делать дырки в навмешах? Я рассчитывал, что он будет как-то сам цеплять хотя бы окружающие статикбоди, но он их не видит, даже если удочерять статикбоди от навмеша или ноды Navigation. Странно.
А вот на второй картинке натуральный баг. Если бот запрашивает путь из точки (0, 0, 0), то Navigation почему-то посылает сначала на угол своего навмеша, а только потом - на конечную точку. Я пробовал смещать бота на (0.1, 0, 0) и (0, 0, -1) - любое смещение от нулевой точки исправляет проблему, т.е. маршрут строится по прямой, но нельзя же предугадать, что бот никогда не наступит на точку (0, 0, 0) во время игры? В реальной игре это может вызвать очень неприятные последствия (у меня тут бот срывался в пропасть, пока я не расширил тестовый полигон, чтобы убедиться, что он потом вернётся)...
Собсна баг смутил даже больше, чем то, что навмеш почему-то не видит статикбоди. Кстати, для чего кнопка "запечь навмеш"? Я её нажал - навмеш просто пропал (лол), пришлось создавать его заново из той коробки.
Вообще, пробую эти навмеши чисто из любопытства, т.к. скорее всего навигацию придётся самому велосипедить. Просто думалось, что навмеш реально может помочь обходить препятствия, но тут чёт проблем ещё больше(
Планирую сделать как-то так:
- есть карта, она по большому счёту никак не меняется (кроме машинок и прочих ригидбоди);
- по карте расставлены т.н. "зоны интереса" и "вейпойнты" - точки, по которым боты ходят;
- когда боту нужно в какую-то зону интереса, скрипт строит маршрут по набору вейпойнтов;
- если бот на пути к вейпойнту видит препятствие, он пытается сам обойти его по кругу;
- боты, находящиеся далеко от игрока, телепортируются от вейпойнта к вейпойнту.
Ну, не телепортируются, а скорее симулируются отдельным фоновым кодом, который планирую прицепить к Godot через GDNative, а уже игровые скрипты запрашивают актуальную позицию ботов у этого кода, когда приходит пора отобразить ближайших к игроку ботов. Следовательно, навмеш мог бы пригодиться только в момент обхода ботом препятствия между двумя вейпойнтами, и то - только когда этот конкретный бот находится поблизости от игрока. Поэтому сильно сомневаюсь, а нужно ли мне вообще возиться с системой навигации Годо, или так обойдусь? Разве что с обходом сложных препятствий проблемы могут возникнуть, но с этими сложными препятствиями ещё нужно столкнуться...
Самая писечка - это когда навмеш строится из блоков. Возьми гридмап для тридэ, засунь в него всего два блока: нав и ненав. В наве есть навмеш, в ненаве соответственно нетути.
Далее заполни все пространство карты блоками нав в гридмапе, а места под статики заполни блоками не_нав. И вот тебе навигация.
Главное чтобы границы навмеша в блоках гарантированно соприкасались, тогда нода навигации корректно соберёт общий навмеш из твоих блоков.
>Возьми гридмап для тридэ, засунь в него всего два блока: нав и ненав
Это какого ж размера должны быть ячейки гридмапа, если я не собираюсь делать кубические карты? То есть где-то препятствие будет условным "полублоком", где-то вообще один маленький столбик или деревце, где-то круглая клумба, а где-то стенка под углом к дороге. То есть с крупными ячейками будет много недочётов, а из мелких делать не вариант, их будет слишком много.
>места под статики заполни блоками не_нав
То есть в реалтайме статики вырезать нельзя? Получается в два раза больше работы - сначала расставить статики, а потом снова расставить их же, но на навмеше...
Я задумывал разрешить ботам ходить везде, где может ходить игрок, с поправкой на то, что они ориентируются на вейпойнты, которыми отмечены основные дороги (чтобы не пытались ломиться напролом, а шли по пешеходным дорожкам, по возможности возвращаясь к ним). Одна из проблем в том, что на пути ботов могут оказаться динамикбоди (куча автомобилей, к примеру), а другая - в том, что карта собирается в рантайме из заплаток-кварталов, соответственно покрывать всё это навмешем будет нерационально, мне кажется.
Пробую заюзать навмеш на случай, если он всё-таки пригодится, т.к. я мало что про него знаю. Так-то покрыть всё вейпойнтами не проблема (плюс должно быть удобно передавать их в dll-библиотеку); для обхода мелких препятствий собираюсь соорудить "зрение" ботам, будут пытаться обходить то, что попадает в конус Area, прицепленный к голове.
>это навигация, а не коллизии
Навигация подразумевает ориентирование в пространстве, а зачем мне ориентироваться в пространстве, если там нет препятствий? Я думал, оно как-то само будет вычитать препятствия из путей...
В параметрах навмеша есть "Parsed Geometry Type", есть вариант "Static Colliders" - это разве не то?
Я пробовал переключать этот параметр, перемещать статик боди по дереву сцены - ноль реакции(
>>654833
>Гридмап имеет все необходимые методы для динамического изменения в рантайме.
Сколько это стоит по ресурсам? Как часто можно делать, чтобы всё не повесилось от 5+ объектов?
У меня температура 37, 5 и начала расти! Походу коронавирус подхватил. Не могу доползти до компа, чтобы накидать тебе проект-пример. Так что давай сам. Суть ты уловил как мне кажется. Тесты сам сделаешь.
Скажу вкратце.
Накидываешь поверх локации гридмап, заполняешь весь объем навами. Не_навы, которые я описал выше, не нужны, объекты будут просто задавать -1 для нужных ячеек, которые нужно вырезать из результирующего навмеша.
Далее. Уровнем выше должна быть нода Navigation, на всякий напоминаю.
У гридмапа есть функции, преобразующие глобальные координаты в координаты своей сетки и обратно. Это именно то, что нам нужно. Игровые объекты при своих перемещениях посылают периодически в гридмап такой запрос: по предыдущим своим координатам установить в совпадающих ячейках значение дефолт (которое ты задал при дизайне сцены) по текущим координатам задать значение -1.
Все. Имеем динамический навмеш, учитывающий как статики, так и динамики.
Это-то понятно, как сделать. Я несколько дней назад уже тыкал гридмап, понимаю, о чём речь.
Проблемы использования навмеша в следующем:
- карта модульная, то есть собирается из кусочков в реалтайме;
- количество и состав модулей заранее неизвестен (я не определился пока);
- размеры карты могут быть большими (ну, допустим, карта города в GTA 3);
- часть модулей могут скрываться из дерева сцены (чанки-кварталы и комнаты в домах).
Даже если взять один гридмап с навмешами на весь город, и вырезать дырки модулями, то это всё равно будет сложно и неэффективно, как мне кажется. Кроме того, навмеш строит путь напрямик, через всё свободное пространство, а мне по идее нужно чтобы боты топали по дорожкам, возвращаясь к ним, если на что-то отвлеклись. Да и в случае "навмеша на всю карту" я не смогу перенести ИИ ботов во внешнюю библиотеку, буду привязан к навмешу Годо.
Я решил расставлять "вейпойнты", каждый из которых в _ready() добавляет себя в глобальное хранилище вейпойнтов (можно сделать иначе, не суть, нужен только один Vector3), а дальше бот запрашивает маршрут до интересующего его места у этого хранилища. Маршрут не предполагает динамические препятствия, он полагается на корректное расположение вейпойнтов внутри каждого модуля. Если у бота возникает на маршруте препятствие, он пытается его обойти (ориентируясь по коллизиям), если не удастся - строит новый маршрут по другим вейпойнтам. Смысл в том, что бот не знает заранее, встретит ли он препятствие на пути, тогда как навмеш заранее строит оптимальный маршрут; массив вейпойнтов - своего рода 3D карта города, где точками отмечены удобные для перемещения дороги, известные ботам, которые они "представляют в голове". Можно, например, скрывать часть вейпойнтов от отдельных ботов, чтобы они делали вид, что не знают дорогу до какого-то объекта.
Рассматривал возможность использовать навмеш на ближней дистанции, то есть на несколько метров возле бота, только чтобы обходить особо сложные препятствия... Кстати, а что будет, если нацепить Navigation на подвижную сущность? Мне даже не нужен полный путь, скорее направление на правильный путь (т.к. в любом случае полный путь может устареть)... Но я сомневаюсь, стоит ли оно того вообще. Мне хочется симуляцию поведения людей, а в жизни "навмешей" не бывает.
Да и, если честно, я уже сомневаюсь, хочу ли делать игру. Вряд ли получится нормальный ИИ даже в рамках игрового мира...
Не вижу проблемы обновлять количество кубов навмешгрида. Просто бери и делай. Решай проблемы по мере поступления. У тебя игры ещё нет, а ты уже думаешь о том, как столкнешься с проблемами. Синдром умной Эльзы, не иначе.
Насчёт ИИ гугли GOAP все современные игры основаны на нем. Реалистичность поведения ботов опирается только на то, несколько грамотно и разнообразно ты создашь goals и actions для системы этой.
Всё, пока, убегаю, меня реанимация ждёт!
Итак, имеем тайлсет - картинку, нарисованную от руки, отсканированную, выровненную по горизонтали-вертикали и скормленную ноде TileMap. Если просто нарезать её на квадратики и расставлять какой-то один квадратик, получится некрасиво. Расставлять тайлы последовательно - долго и нудно, сетка довольно большая. Есть ли способ сделать так, чтобы тайлы из тайлсета расставлять в определённом порядке? Я нашёл только чтобы на границе тайлового скопления всегда появлялись определённые тайлы и чтобы тайлы чередовались с некоторой вероятностью.
И да, я ещё не искал, но всё же спрошу, раз уж пошла такая пьянка. С отдельными тайлами же можно как-то работать скриптами? Например, чтобы при попадании пули тайл "brick" превращался в "Brick damaged", а при попадании второй пули - в "brick broken", у которого уже нет коллизии и другой z-index.
По первому пункту гугли автотайл. Если я правильно понял. Будет тебе рисоваться автоматически поле из центральных тайлов, обрамлённое краевыми тайлами.
По второму пункту гугли map_to_world, world_to_map о чем говорилось выше но для тайлмапов все аналогично гридмапам. При коллизии физических тел движок даёт тебе координаты этой коллизии. Далее находишь координаты тайла и выставляешь желаемый индекс (индекс тайла с разбитым кирпичом) по известным тебе на этом этапе координатам можешь спавнить эффект разрушения с летящими в стороны осколками.
>Если я правильно понял. Будет тебе рисоваться автоматически поле из центральных тайлов, обрамлённое краевыми тайлами.
Я не он, но вижу, ты неправильно понял. У него тайлы нарисованы от руки, и поэтому если один и тот же квадратик повторять по сетке, видно сетку, а это некрасиво. Забыл, как называется этот эффект... И вот он хочет вместо одиночных тайлов лепить сразу группами типа 2x1 или 2x2, я так думаю. Хотя по-хорошему нужно просто тайлы заново перерисовать...
>>655288
>Есть ли способ сделать так, чтобы тайлы из тайлсета расставлять в определённом порядке?
Не знаю, как в Годо, не пользовался, но в Tiled и других тайловых редакторах для этого вроде можно выделить сразу несколько ближайших тайлов, чтобы лепить сразу группами типа 2x1, 2x2, 2x3, 3x3, 3x1 и т.п. Но всё-таки рекомендую перерисовать тайлы, если ты видишь чёткую сетку - значит, плохо нарисовал тайлы.
Y-sort это не то. К тому же никакого вопроса про z-порядок я не задавал, там всё просто и понятно.
>>655300
Сенкс, няш, ты всё правильно понял. Вот только про перерисовку никакой речи быть не может: неровные линии создают неповторимый шарм, графика прям живая и дышащая становится. Попробую Tiled; если и там не получится, тогда ручками придётся каждый тайл ставить.
> Я думал, оно как-то само будет вычитать препятствия из путей…
И раз
https://www.youtube.com/watch?v=_urHlep2P84
И два
https://www.youtube.com/watch?v=A1xjUuRZmWQ
>неровные линии создают неповторимый шарм, графика прям живая и дышащая становится
Это понятно, но тебе всё равно ведь придётся замыкать тайлы. Не 1x1, так 2x2, не 2x2, так 3x3...
>Попробую Tiled; если и там не получится
Там-то точно получится, но для импорта понадобится инструмент: https://godotengine.org/asset-library/asset/158
>>655497
Спасибо, посмотрю.
if Input.is_action_just_released("reset_scene"):
var error = get_tree().reload_current_scene()
С помощью print()-ов выяснил, что во время перезагрузки ноды-синглтоны не сбрасывают состояние.
Т.е. если у меня в синглтоне хранится какой-то массив, перезагрузка сцены не сбрасывает его в ноль.
Мне что, отдельный метод для сброса писать? Нет способа определить момент сброса сцены?
Алсо, что если сделать синглтоном HUD игрока? Вроде логично, он ведь только один должен быть...
> во время перезагрузки ноды-синглтоны не сбрасывают состояние
Само собой. Ты бы remote сцену глянул бы хоть раз, что она из себя представляет:
\SceneTree
-\root
--\singleton1
--\singleton2
--\your_current_scene
Из вышеприведённого примера видно, что синглтоны не что иное, как отдельные от сцены ветки общего дерева. Просто они регистрируют свои имена в пространстве имён дерева сцены так, что ты видишь их по именам в любом скрипте. Соответственно, за эту регистрацию и отвечает галочка "синглтон" в автозагрузке. При перезагрузке куррент-сцены, это очевидно не затрагивает соседние ветви дерева. Удаляется зарегистрированный в дереве чайлд, который олицетворяет куррент-сцену, затем загружается его новый инстанс.
> что если сделать синглтоном HUD игрока?
Я всегда так и делаю, а ещё главное меню. Да и весь интерфейс. И ещё кучу сопутствующих мелочей, которые нужны всегда, на всех этапах рантайма игоры. Например, фоновую музыку. Только галочки синглтона с них снимаю, чтобы не возникало соблазна обращаться к ним напрямую, портя стройность игровой логики. Сценовые ноды не видят автозагруженные ноды. Однако есть несколько способов обратиться к ним:
1. Get_tree().get_root().get_node("your_autoloaded_node")
2. Get_node("/root/your_autoloaded_node")
3. Мой любимый способ. Создаёшь специальную ноду-маршрутизатор или менеджер сообщений или, как некоторые называют, диспетчер событий. Эту ноду пихаешь в автозагрузку с галкой синглтона. В скрипте этой ноды объявляешь кучу кастомных сигналов, например load_game, update_UI, set_state и прочее нужное тебе. Далее, ноды, которые должны получать данные коннектятся к этим глобальным сигналам у себя в ready(), event_manager.connect("signal_name", self, "function_name") дисконнектить не нужно, об этом движок заботится автоматически. Лично у меня крошей не возникало. Кстати, коннектить можно не только свои функции, но и другого синглтона, например, кидаешь в автозагрузку game.gd в котором описываешь глобальные функции и константы. Тогда будет так: event_manager.connect("signal_name", game, "function_name_in_global_game") Ноды, которые должны передавать данные, делают, когда требуется event_manager.emit_signal(custom_data) и подписанные на этот сигнал объекты получают содержимое custom_data и делают с этим содержимым свои дела. Если содержимым будет Dictionary, то нода-эмиттер может так же получать ответ, так как словари передаются по ссылке. Только ответ надо разделять по ключам, если ресиверов сигнала больше одного. Очень крутая система, уважающая инкапсуляцию (которая не сокрытие, напоминаю, а концентрация логики в "капсуле" внутри конкретного модуля) то есть скрипты нод независимы максимально. Им требуется только наличие как минимум одного синглтона, о чем они сообщат на этапе компиляции и ты этого не пропустишь. При желании этот момент можно тоже защитить от дурака, ища в ready() синглтон по его ожидаемому имени из п.2. (т.к. он будет потомком root) и если не найден, не подписываться на сигналы и не излучать их. Но я до такой степени не заморачиваюсь, т.к. работаю сам и принимать дураков в команду вроде как не планирую))
>синглтоны не что иное, как отдельные от сцены ветки общего дерева
Это я знаю. Но каждая ветка - это сцена, так? Почему тогда reload_current_scene() удаляет только
>зарегистрированный в дереве чайлд, который олицетворяет куррент-сцену
Вместо того, чтобы удалять вообще всех детей root-ноды?
Нет, я, конечно, понимаю, что так сделано для того, чтобы можно было через синглтон переносить данные между разными сценами, например, текущий прогресс игрока между уровнями, или глобальные настройки игры какие-то, но мне почему-то казалось, что "перезагрузка сцены" по идее должна сбрасывать вообще всё. Дело в том, что у меня на загрузке сцены некоторые ноды в _ready регистрируют себя в одном синглтоне, и поэтому если просто сбрасывать сцену, будет утечка памяти и обращение к nil; получается, мне необходимо перед/после обращения к reload_current_scene() дополнительно делать запрос к синглтону, чтобы он сбросил своё состояние... Мне нетрудно, но выглядит не совсем логично.
>что если сделать синглтоном HUD игрока?
Уже сделал так, действительно, намного удобнее получилось. Просто думал, что синглтоном не может быть что-то визуальное, да и тот же интерфейс придётся периодически скрывать/показывать, он ведь не всегда нужен...
>чтобы не возникало соблазна обращаться к ним напрямую
В чём проблема писать HUD.show_help(true)? Если вдруг дисплей отвалится, то и стартовать игра не должна.
Или вот у меня CityNavigator.find_closest(point), бот ведь не будет использоваться где-то помимо города...
>коннектятся к этим глобальным сигналам у себя в ready
Вот с этими сигналами так много проблем. Коннектить нужно, излучать... А когда они вообще доходят? Это ведь не прямой вызов процедуры, неизвестно, дойдёт ли вообще. Про систему сообщений я знаю после изучения ECS, но так руки и не дошли сделать своими руками, с трудом понимаю, как это может работать. Раньше делал что-то похожее, но там рассылалось от каждого всем, а уже получатель определял, нужно ли ему то, что он получил...
Кстати, если использовать сигналы вместо прямых вызовов процедур, нагрузка на кадр будет меньше? А то вот подумываю о том, чтобы запускать субгенераторы через сигналы - по моему опыту, если каждая сцена определяется со своим состоянием в своём ready(), то сцена начинает грузиться несколько секунд (пока все субсцены не определятся), а при чуть более сложной генерации переполняется стек (о_О), это нехорошо. Вообще не знаю, чё делать, если б на Паскале писал, я бы просто загнал генерацию в отдельный поток и/или делал её предварительно, а тут приходится как-то мудрить с отдельными скриптами, не настраивать же все сцены из одного скрипта...
> каждая ветка - это сцена, так?
Не совсем.
Есть сцена как файл, который ты сохраняешь в формате (t)scn. Это полноценная сцена со своим единственным корнем-родителем и кучей детей. Однако, эта сцена входит в существующую на этапе исполнения твоего конечного приложения сцены как один из детей. Здесь конечно есть повод поругать Хуана в срачетреде за путаницу в терминах. Следует различать сцены-ресурсы, которые десериализуются игрой и их инстансы включаются в общее дерево, и различать собственно само дерево сцены (SceneTree) олицетворяющее главный цикл приложения и являющееся создателем всего дерева сцены. Вроде как всё есть сцены, но я предлагаю держать в уме, что те сцены, которые ты создаёшь в редакторе, это таки префабы, а не сцены. И сценами они не становятся. Они становятся ветвями в дереве одной единственной сцены. Как и куррент_сцене, так и аутолоадед_синглетонц. Ещё раз рекомендую ознакомиться с remote (удалённой) сценой, при запуске игры в редакторе.
Забыл дать пояснения к скрину. В данном скрине куррент сцена - это menu_location, фон для главного меню с простенькой анимацией. Всё остальное - автолоады, из которых с галкой синглтона только evman, config и game. Когда я делаю загрузки или перезагрузки куррент сцены (то есть, когда загружаю собственно игру), автозагруженные модули получают необходимые сигналы, чтобы изменить их состояние. Например, задать фоновую музыку, скрыть меню, показать HUD. Наборы этих действий стандартно входят в такие процедуры как загрузка сохранённой игры, старт новой игры. При включении режима паузы часть из них автоматически переходит в режим паузы, а некоторые принудительно выставлены в режим process и получают свои сигналы, например, фоновый плеер немного приглушает громкость.
> Вообще не знаю, чё делать, если б на Паскале писал, я бы просто загнал генерацию в отдельный поток и/или делал её предварительно, а тут приходится как-то мудрить с отдельными скриптами, не настраивать же все сцены из одного скрипта…
Я тоже старый паскалист. Правда с потоками особо не работал, хоть и понимаю их суть. Удивляюсь, почему ты, обладая знаниями паскаля, не понял как это всё устроено. Там вообще ничего сложного нет.
Как паскалист паскалисту хочу подсказать (а может напомнить, если уже сам знаешь), что аналогами функций и процедур модуля в гдскрипте (равно как и в шарпе) являются static func. Это полный аналог. Статическая функция уже не является методом объекта, описываемого скриптом. У неё нет доступа к методам и полям-переменным. Это те самые функции, которые в модулях паскаля писались без префикса в виде имени класса. Сам понимаешь теперь, для чего их можно применять. Например, чтобы выполнить некий расчёт одной строкой, вызвав статическую функцию, в которой создастся экземпляр класса, вернёт какие-то данные и уничтожится.
> Вот с этими сигналами так много проблем. Коннектить нужно, излучать… А когда они вообще доходят? Это ведь не прямой вызов процедуры, неизвестно, дойдёт ли вообще.
Сигналы это полный аналог ивентов в том же дельфи. Полнейший. Доходят так же. В рамках фрейма, в котором излучены.
> систему сообщений
Сообщения - есть фундаментальное понятие программирования, есть в большинстве парадигм, методик, архитектур, паттернов. Есть сообщения и в годо. Однако, это совершенно иная подсистема и её не желательно путать с сигналами-ивентами. С помощью сообщений (оконных, NOTIFICATION_WM_QUIT_REQUEST), я например, отслеживаю закрытие приложения и выполняю необходимые действия, вплоть до отмены закрытия, если игрок передумал в диалоге ДА/НЕТ.
>В годо есть вообще управляющие сиволы типа \n ? Нашел только обоссаный newline()
Ты хотя бы попробовал использовать \n, прежде чем задавать вопрос здесь? -_\\
Освой форматирование строк. Такая крутая тема! Всем рикаминдую.
text = "FPS: %s\nObjects: %s\nNodes: %s\nOrphans: %s\nVertices: %s" % [fps, objs, nodes, orphans, vertices]
Ну ты понел. И есть ещё варик со словарём, чуть длиннее и более подходит для крупных текстов.
Именно перл и является очередным зумерским высером, внучок.
Интерполяция чаще всего подразумевается линейная, когда lerp(from, to, delta) а что вы, зумеры подразумеваете под интерполяцей строк? Ты дяже объяснить этого не сможешь, потому что нет в стрововом форматировании никакой интерполяции. А тот дегенерат, что придумал использовать этот термин, будет гореть в аду.
Я не понимаю, что и зачем ты пытаешься объяснить. Я говорил, что меня смутило, что перезагружается не "root", а только одна из его веток, которая помечена как "текущая сцена". Изначально я начал использовать reload_current_scene() в качестве замены нажатия F5 в редакторе, чтобы не перезагружать всю игру целиком, если мне нужно сбросить сцену для теста. Выглядит нелогичным, что нода-синглтон (UI) имеет особые привилегии перед обычной нодой (menu_location).
>рекомендую ознакомиться с remote
Да знаю я про remote, ещё несколько лет назад в туториале к Godot 2 про неё узнал (а потом забил на Godot и вообще любые готовые движки и сам геймдев). Толку-то от неё, если у меня в тестовой сцене сотни нод. Она может помочь только в отладке мелких сцен, и то если какая-то ошибка возникнет...
>>655742
>Правда с потоками особо не работал, хоть и понимаю их суть.
В данном конкретном случае суть в том, чтобы не тормозить главный поток. В обычном приложении главный поток может общаться с пользователем через нажатия кнопок и всякие анимации, тогда как в фоне крутится несколько потоков, занятых долгими или тяжёлыми процессами. Конкретно в игре я бы хотел (попробовать) выделить генерацию в отдельный поток, чтобы игрок мог сразу бегать по карте, пока она ещё не до конца прогрузилась. Да и систему ИИ было бы неплохо выделить в отдельный поток, но это я планирую сделать с помощью GDNative и всё того же Паскаля; можно и генерацию так же сделать, но я хотел поэкспериментировать на GDScript для начала. Знаю, что многопоточность можно симулировать на уровне приложения, но париться с этим желания нет, раз уж мы сидим на многопоточной ОС.
>Статическая функция уже не является методом объекта, описываемого скриптом. У неё нет доступа к методам и полям-переменным
Тогда какой в ней смысл? Память она всё равно занимает, выделить в отдельный файл-модуль всё равно нельзя, выполнение вызывающего кода всё равно блокирует. Я когда в ООП-стиле на паскале пишу, практически не создаю простые функции и процедуры, а static методы вообще никогда не создавал...
>Сигналы это полный аналог ивентов в том же дельфи. Полнейший. Доходят так же.
Эммм, я не создавал свои собственные ивенты в Delphi/Lazarus, но насколько мне известно, TApplication работает в единственном потоке, и событие мгновенно вызывает связанный с ним обработчик, ничего никуда не "доходит". Это значит, что если обработчик содержит тяжёлый код, срабатывание события вызовет зависание основного потока... Нехорошо.
>Однако, это совершенно иная подсистема и её не желательно путать с сигналами-ивентами
Ну "система сообщений" в моём представлении хранит в себе "сообщения" и периодически пытается доставить эти сообщения подключённым к ней сущностям, когда те будут готовы к приёму. То есть она должна работать в отдельном потоке, и раздавать сообщения не мгновенно, а по мере возможности. Про сообщения из WinAPI прекрасно знаю и много раз работал с ними, они примерно то, о чём я говорю, наверное, т.к. они доставляются по мере возможности - если приложение зависло, очередь сообщений забивается, например.
>Удивляюсь, почему ты, обладая знаниями паскаля, не понял как это всё устроено. Там вообще ничего сложного нет.
Главным образом я не могу понять концепцию "скриптов". Потому что когда я пишу код на Паскале или любом другом компилируемом ЯП, я чётко вижу единственную точку входа в программу, хотя бы примерно понимаю, что происходит под капотом того же TApplication, когда и при каких обстоятельствах вызываются все процедуры. А при написании скрипта для игрового объекта в любом игровом движке у меня ощущение, будто скрипт "авось выполнится, а может и нет", и вообще не имеет никакой связи с другими скриптами. Очень трудно писать код, когда он не является цельной программой.
Я вот вижу, что .gd-файл - это класс, и от него можно наследоваться, что примерно похоже на подключение модуля, но собственно подключения модулей так и не нашёл. То есть, например, для каких-то утилит мне нужно создавать отдельный класс, добавлять его в автозагрузку, и обращаться по имени класса, вместо того, чтобы явным образом подключить необходимый модуль к нуждающемуся в нём скрипту...
Эх, если б я мог осилить математику и не ленился/боялся, я бы давно на своём движке кодил. Может быть, даже сделал бы свой собственный ЯП, кто знает, заготовки валяются без дела...
А, ну да, я так-то планировал собственную скриптовую систему, и поэтому понимаю, что каждый скрипт обрабатывается независимо интерпретатором, но вместе их связывает общее хранилище каких-то данных и общая библиотека базовых функций интерпретатора. Вот только не зная подкапотной работы интерпретатора, трудно представить и удерживать в голове то, как будут вести себя твои скрипты, и это раздражает.
Вот, кстати, второй раз забываю спросить - почему в GDScript не предусмотрен деструктор класса? Роль конструктора по идее выполняет ready, хоть он и вызывается позже enter_tree, но деструктора нет. Пробовал использовать какой-то костыль, но он то ли не работает, то ли работает не так, как я думал, а тот же exit_tree в качестве деструктора нельзя использовать, т.к. нода может покидать дерево и возвращаться в него много раз за время своей жизни. Странно и неудобно.
>что вы, зумеры подразумеваете под интерполяцей строк?
Кстати, он прав, интерполировать строки действительно возможно.
И таки интерполяция строк была раньше интерполяции чисел, лол)
> Я не понимаю, что и зачем ты пытаешься объяснить. Я говорил, что меня смутило, что перезагружается не "root", а только одна из его веток, которая помечена как "текущая сцена". Изначально я начал использовать reload_current_scene() в качестве замены нажатия F5 в редакторе, чтобы не перезагружать всю игру целиком, если мне нужно сбросить сцену для теста. Выглядит нелогичным, что нода-синглтон (UI) имеет особые привилегии перед обычной нодой (menu_location).
Утро вечера мудренее. Может завтра перечитаешь и поймёшь, может за ночь анон поумнее меня обеснит. Если вкратце: root не то, что перезагружается. Это вообще-то Viewport. Он как бы должен всегда существовать, это олицетворение контекста, в который выводится игра.
> В чём между ними разница?
UI - загружен через автолоад.
menu_scene - загружена через change_scene() и является current_scene. После того, как игра стартует, на её место встаёт другой инстанс из файла tscn. Другая "сцена", которая, как я коряво пытался объяснить, не вся сцена, а подсцена сцены.
> В обычном приложении главный поток может общаться с пользователем через нажатия кнопок и всякие анимации, тогда как в фоне крутится несколько потоков, занятых долгими или тяжёлыми процессами.
https://docs.godotengine.org/ru/latest/tutorials/threads/thread_safe_apis.html
>тебе всё равно ведь придётся замыкать тайлы
Я нарисовал два почти одинаковых квадрата (набора) 8х8 (с учётом неровных границ они превратились в 10х10), получилось достаточно разнообразно, чтобы в любой конфигурации найти более-менее незаметный стык.
>Там-то точно получится, но для импорта понадобится инструмент:
Аригато, я уже всё нагуглил и опробовал.
Вообще, выглядит как правда. И ты можешь сам это проверить. Можешь обезопасить себя, конечно, но это лишнее, ИМХО. Порядок загрузки, порядок чтения файлов это все вещи фундаментальные и их менять не предполагается. Когда меняют такие фундаментальные вещи, то заявляют вслух о несовместимости новых версий со старыми.
>порядок элементов одного уровня в древе сцены соответствует порядку загрузки
Да, это так. Попробуй набросать несколько нод с кодом:
func _enter_tree():
print(name, " enters tree")
func _ready():
print(name, " are ready")
func _exit_tree():
print(name, " leaves tree")
Когда запустишь, увидишь, что ноды входят в дерево и готовятся к работе в прямом порядке, а выходят в обратном порядке. Иногда это может быть важно, да. Например, если у тебя две камеры, то первой перехватит управление та, что войдёт дерево раньше, и через неё будет идти рендеринг - поэтому если камер несколько, Player со своей камерой должен находиться выше остальных камер.
>все полетит к херам собачьим?
Полетит или не полетит - попробуй и узнаешь сам. Но скорее всего полетит, потому что соседняя сущность ещё не существует и будет обращение к null (точнее get_node() не сможет найти и вернёт null, к которому ты обратишься). Лучше переделай код, тут вот выше уже обсуждалось, что лучше иметь обращения только к потомкам (ready() предка вызывается после всех ready() потомков).
Да мне нужно было тупо сразу Википедию почитать:
>В жанре 3D-шутеров используются намного более ограниченные пространства, которые не так легко разделить на узлы. Здесь взамен узлов используются так называемые waypoints (дословно с англ. — «точки пути»). Waypoints — это нерегулярные и вручную установленные узлы, которые содержат информацию о том, к каким другим узлам возможно добраться от данного.
Короче Navigation Godot'а нужен по большому счёту для стратегий, где не бывает сложной геометрии уровня.
Делаю двадэ-анимацию по принципу "одна кость - одна картинка". Чтобы никаких артефактов на сгибах. Делаю по инструкции как у этого чувака https://www.youtube.com/watch?v=QL57J3anDTU - и стопорюсь на этапе IK. Правая рука ведёт себя правильно, причём не по старому методу, описанному в видео, а по новому, про который он сказал, мол, пока ещё не работает (у него версия 3.1). А с левой рукой не срабатывает. Как будто никакой привязки графики к костям нету, картинка не двигается вместе с костью, к тому же кость растягивается, будто никакого IK нету. Хотя я абсолютно одинаково всё сделал с левой и с правой стороной.
То есть, я двигаю кость предплечья, само предплечье с ней вместе двигается, плечо стоит на месте, кость плеча растягивается. Двигаю кость плеча - двигается плечо и предплечье вместе с костью. Попробовал отсоединить скелет, всё заново просинхронизировать. Смог заставить правильно работать одну ногу, вторая не хочет. Куда копать? Что курить? Где гуглить?
Мы тут экстрасенсы что ли? Не проще найти готовый шаблон/демо? Пикрил, например, хоть это и 3D, но прицип скорее всего тот же.
>Не проще найти готовый шаблон/демо?
Нет, не проще. Терпеть не могу в чужом коде ковыряться.
Впрочем, я уже нашёл более простое решение для себя: https://docs.godotengine.org/ru/latest/tutorials/animation/cutout_animation.html#doc-cutout-animation - гораздо меньше возни, никаких искажений и всё работает.
А когда она будет-то, четвёрка эта? Надеюсь, обратную совместимость не сломают...
Такое сообщение выбрасывается, когда ты где-то теряешь ссылку на сущность. Снабди код проверками на null, где возможно, и выводи собственные ошибки в консоль, чтобы знать, где ссылка теряется. Ну или просто тщательно код пересмотри, где вероятнее всего могут возникать null-ы?
>во время вызова функции сохранения
Функцию сам писал же? Вот в ней и нужно разбираться, где там у тебя ссылки на null.
Сам я пока не разбирался в функционале паузы и сохранения, но по идее paused просто меняет внутреннее состояние нод, и не должно ломать ссылки. Поэтому скорее всего ты сам где-то ссылки теряешь, или небезопасно уничтожаешь какие-то объекты. Может, какой-то код написал и забыл про него, а он сейчас реагирует неправильно.
Привет!
Добро пожаловать в Годо-15! Лучший тред из оставшихся.
Я сегодня как раз размышлял над удобной системой схоронения. И придумал следующие положения:
1. Данные сохранения подготавливаются как словарь (Dictionary) в глобальной области (автозагруженном скрипте).
2. Сущности, которые должны сохранять данные обладают компонентом сохранения, который гибко настраивается.
3. Развешиваем компонент на нужные ноды.
4. Подписываем компонент на сигналы сохранения и загрузки.
Вот накидал примерчик. Я разделяю свойства полученные через геттер, чтобы в дальнейшем выставлять их через сеттер, а остальные напрямую. Ну и save_example это разумеется не настоящие данные сохранения, а показанные для примера.
Логика токова: когда игрок нажимает эфпяточку, генерируется сигнал collect_save_data после чего все подписанные на него сэйверы наполняют словарь данными, разбитыми, как видно из кода по овнерам (рутам субсцен), парентам и могут сами содержать подразделы-словари. Затем нужно подождать, пока все данные соберутся. Я пока ещё не придумал, как. После того, как данные соберутся, генерируется сигнал save_game который собственно записывает содержимое в файл.
Загрузка работает в обратном порядке. Но надо дополнительно смотреть, существуют ли указанные в файле объекты и если нет - сначала создавать, а потом разсериализовывать им свойства.
И да. Разумеется, это работает с пользовательскими свойствами, созданными в скриптах. Вот я создал свойство, указал его в инспекторе и вуаля!
Кому-то может показаться неудобным выставление свойств строками в массиве - нет защиты от опечаток. Штош. Пишите аддон. Чтобы как у аниматора ключики - у сэйвера стояли значки для отбора сохраняемых свойств.
По-моему твой способ мудрёный и не для всякой игры подойдёт.
Я вот собираюсь попробовать это - https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
Т.к. мне вся сцена целиком нужна, а не только отдельные свойства отдельных объектов...
И почему добавление random() так сильно замедляет загрузку сцен?..
Задача: найти всех потомков ноды, имеющих определённый тип (например, RigidBody2D), и со всеми проделать одну и ту же операцию (отключить обработку физики; я видел пару дней назад, как это делается, но уже тот видос потерял, придётся снова искать). Вот. Как найти всех потомков, соответствующих заданному типу? Ясно, что циклом for. А дальше? Анончик, может, какой-нибудь тутор по теме подкинешь?
Это очень просто:
for child in get_children():
if child is RigidBody2D:
(child as RigidBody2D).add_collision_exception_with(self)
Оператор is проверяет соответствие типу или классу.
Не уверен, нужно ли после проверки приведение типа (as), но без него подсказка в редакторе не работает.
...Блин, опоздал)
>>656718
1. Зачем отдельную переменную заводить?
2. Если оператор as ниасилит приведение типа, игра должна упасть с ошибкой.
>Не уверен, нужно ли после проверки приведение типа (as)
>>656722
>Переменная там чтобы не писать все по два раза как у тебя
Я тут подумал, похоже не нужно делать лишнее приведение:
for child in get_children():
if child is RigidBody2D:
child.add_collision_exception_with(self)
Да, подсказки в редакторе кода не будет (т.к. подсказка не знает, какого типа child), но и ошибки тоже не будет.
Попытаться вызвать метод можно на любой объект, но сработает он только там, где действительно есть.
Поскольку мы уже проверили, что child нам подходит, мы можем вызывать из него что нам нужно.
Зачем множить сущности без необходимости? Подсказки тебе нужны будут только один раз при написании кода, а память под переменную будет выделяться каждый раз, когда этот код будет выполняться (возможно, 60 раз в секунду, лол). Может мы и пишем на скриптовом ЯП, которой по определению неполноценен в сравнении с компилируемыми ЯП, но всё-таки должны думать о производительности нашего кода.
>Разве? Мне где-то попадалось, что в Годоте все переменные это ссылки.
Не знаю на счёт "всех", но конкретно доступ к экземплярам классов идёт по ссылкам, как и в любом другом ЯП - то есть a = b не создаёт копию, а копирует ссылку (было бы глупо делать так с обычными типами). Вопрос в том, куда копирует, сколько весит ссылка, насколько дорогая эта операция и оптимизируется ли она интерпретатором?
В FreePascal, например, указатель занимает 4 байта для x86 и 8 байт для x64 (в C++ наверняка так же). В GDScript вес может быть меньше (т.к. адресация не в реальной RAM, а в интерпретаторе), но при этом неизвестно, какую информацию он несёт в себе помимо ссылки (может нести сведения о типе, как Variant).
Впрочем, да, это экономия на спичках, если только не делается много раз каждый кадр. То есть даже такая маленькая экономия в каком-то цикле, вызываемом каждый кадр, может оказаться существенной, но в остальных случаях заметных отличий не будет. Но речь как раз шла о for, в котором на каждой итерации создаётся (var...) переменная. Возможно, если создать переменную перед циклом, а в цикле только менять ссылку внутри неё, будет немного оптимальнее, но я предпочёл бы вообще не создавать лишнего. Переменная-итератор цикла уже хранит нужную нам ссылку, так зачем создавать её копию?
...я подумал - скорее всего все переменные тут - это Variant. Отличие Variant от Pointer в том, что Pointer хранит ссылку на какую-то область памяти, а Variant хранит любые данные и тип этих данных, в т.ч. может хранить Pointer. Pointer может указывать на любые данные в памяти, но он ничего не говорит ни об их типе, ни об их размере. Variant сам по себе может содержать любые данные, но тратится лишнее время на определение типа данных перед каждой операцией с ним. Но поскольку ссылка на экземпляр класса хранится в обычной переменной (в которой может храниться что угодно), то мы получаем Pointer, упакованный в Variant, а это всё значительно усложняет.
Кстати, когда искал про массивы в GDScript, обнаружил, что обычный массив[] - это массив Variant, из-за чего работа с массивами в GDScript медленная. Разработчик обещал когда-нибудь ввести типизированные массивы для увеличения производительности, но пока есть только Pool-ы... Значит, операции с переменными не такие уж и дешёвые.
>Но речь как раз шла о for, в котором на каждой итерации создаётся (var...) переменная.
Речь шла о том, чтобы один раз перебрать всех детей одной ноды. То есть, сам цикл не очень большой, вызываться будет далеко не каждый кадр.
Впрочем, да, лучше иметь привычку экономить ресурсы даже в таких мелочах.
Если кто не знал:
https://ru.wikipedia.org/wiki/Скан-код
Суть в том, что клавиши клавиатуры имеют аппаратно прошитые скан-коды, а уже драйвер клавиатуры подбирает каждому скан-коду соответствующий код клавиши текущей раскладки ОС. Приложение, по сути, получает два кода - код клавиши и скан-код, а что из них использовать - дело разработчика. При наборе текста, например, нам не важно, где расположена клавиша, нам важен только её код (буква, цифра, символ), а вот в играх важно только расположение клавиш, т.е. нужно ориентироваться на скан-коды (исключение - чат, это набор текста).
Понятное дело, что можно сделать настройку клавиш в игре, но хотелось бы иметь нормальный биндинг по умолчанию для любой раскладки.
Для примера, сравните хотя бы QWERTY и AZERTY - привычный нам WASD во Франции выглядит как ZQSD.
>Я даже более того тебе скажу. В некоторых крупных играх бывает такая же проблема с раскладками. НЯП, в Doom Eternal она есть, в "Сталкере" точно была.
Наличие проблем в крупных играх не говорит о том, что нужно добавлять эти пробелы в свои игры)
>>656840
>распространяется только на детей, внуков уже не берёт. А если надо обработать более-менее разветвлённое дерево?
Как уже сказали, рекурсия. Два варианта: либо такая функция:
func do_work(obj):
for child in obj.get_children():
if child.get_child_count() > 0:
do_work(child)
# тут работаем над самим child
else:
# тут работаем над самим child
Либо, если это делается в _ready(), тогда можно просто повесить скрипт на каждую ноду: _ready() вызывается последовательно сначала у самых дальних потомков, а потом постепенно поднимается до главного предка. Т.о. сначала вызовутся циклы у потомков, потом у их предков, и т.д. до главного предка. Но тут всё зависит от того, что за работу нужно сделать...
То есть, какого-то простого метода, чтобы в одну строчку, как get_children(), не существует, я правильно понял? Надо описывать свою функцию для такой рутинной операции? Океей. Это немножко странно для годота, я уже успел привыкнуть, что на всякую объектную рутину здесь есть готовые функции, которые надо просто знать. Ещё и этот >>656852 хитрец загадками говорит, своими намёками утвердил меня в мысли, что есть однострочное решение.
func do_work(obj):
# можно сделать что-то с объектом вот тут
for child in obj.get_children():
if child.get_child_count() > 0:
do_work(child)
# а можно и вот тут, лишь бы не в теле цикла
Спасибо за пояснения, я бы так и долбился головой об стену, пытаясь найти несуществующее однострочное решение.
хотя я всё ещё считаю странным, что у get_children() нет аналога, который бы перебирал всё потомство, а не только детей
Всё, нашёл!
> Node find_node ( String mask, bool recursive=true, bool owned=true )
Эта функция подозреваю, медленная, ибо ищет ноды по строковому паттерну. И работа с ней немного отличается. Нужно юзать while пока функция не вернёт нулль. Начал писать код, но всё стёр. ВРЕДНО! НИЗЯ! Юзайте get_children() по индексам.
>Только ты с else перемудрил, ящитаю. Оно там лишнее
(тут было многабукав) ...а, ну да. Если сделать так, как на скриншоте, то else не нужен. Ох уж эти питоновские отступы, без них в коде можно запутаться...
>>656857
>простого метода, чтобы в одну строчку, как get_children(), не существует
Вряд ли. Даже если бы он существовал, под капотом там примерно такая же хрень и была бы, только вместо непосредственной работы собирался бы массив, что увеличивало бы общие затраты ресурсов. Лучше всего работать с минимальными инструментами, используя их так, как нужно, чем забивать гвозди микроскопом...
>описывать свою функцию для такой рутинной операции
Я бы не сказал, что эту операцию приходится часто выполнять. Вот тебе зачем это понадобилось?
>>656861
Ты сейчас лишний раз вызываешь do_work() на бездетные ноды. Если у тебя таких мало (что вряд ли), то ладно, но если где-то много одноуровневых бездетных нод, то на каждую будет во-первых лишний вызов функции, во-вторых лишняя проверка их бездетности (она уже выполняется в if). Учитывая то, что функция рекурсивная, то есть забивает собой стек вызовов, от лишних её вызовов лучше избавляться.
>хотя я всё ещё считаю странным, что у get_children() нет аналога, который бы перебирал всё потомство
Ничего странного. Если бы такая функция была, она должна была бы формировать длинный массив всего потомства, а потом ты бы проходил по нему циклом. То есть получалась бы двойная работа - сначала собрать массив, потом пройти по нему. Нет, мог бы быть вариант типа do_work_on_children(parent, method, recursive) - который будет вызывать метод method() на каждого потомка parent, но я не уверен, можно ли сделать такой обработчик на GDScript (для этого нужна возможность передавать указатель на метод и вызывать метод по указателю). В функциональных ЯП такие обработчики - обыденность, в императивных же таким занимаются редко (хоть и можно).
>>656863
>Эта функция подозреваю, медленная
Правильно подозреваешь, get_children() тупо возвращает уже имеющийся массив ссылок на потомков, а find_node() пытается найти в этих массивах конкретную ноду. При этом find_node() возвращает первую попавшуюся ноду, а не массив всех подходящих, что не имеет смысла, если только ты не удаляешь все ноды с определённым именем.
>Нужно юзать while пока функция не вернёт нулль
??? Как она вернёт нуль, если ты не удаляешь отданные ею ноды?
В коде да, а в списке действий? Не хардкодить же в скриптах.
> мог бы быть вариант типа do_work_on_children(parent, method, recursive) — который будет вызывать метод method() на каждого потомка parent, но я не уверен, можно ли сделать такой обработчик на GDScript (для этого нужна возможность передавать указатель на метод и вызывать метод по указателю)
Есть такое у нас.
1. call(), call_deferred() возможность вызвать метод по строковому имени.
2. FuncRef объект, который реально хранит ссылку на метод, нужно удалять/очищать вместе с объектом, иначе - крош.
>>656902
Только что проверил на линуксе. Ввод работает только в английской раскладке. Причём и в игре и в редакторе (шоткаты не работают). Как минимум в линуксе обработка идёт через коды буков, а не сканоды. Хотя в винде такой проблемы не было, ЕМНИП.
>Ты сейчас лишний раз вызываешь do_work() на бездетные ноды.
В каком месте? if Child.Get_Children_Count() > 0: do_work(Child) - если у ноды есть потомки, то вызываем, а если нет, то проходим мимо.
>Даже если бы он существовал, под капотом там примерно такая же хрень и была бы, только вместо непосредственной работы собирался бы массив, что увеличивало бы общие затраты ресурсов.
Тащемта таких вещей в Годоте полно.
>Вот тебе зачем это понадобилось?
Пытаюсь 2д-рэгдолл на коленке собрать. И даже уже собрал. Но для полного счастья ему нужно сначала выключить физику для каждой части тела, а потом, когда персонаж умирает, включить обратно. Части тела выстроены в иерархию с узлами из ригидбодей, потому что так удобнее анимировать.
>>656909
>Только что проверил на линуксе. Ввод работает только в английской раскладке.
В линуксе такое повсеместно. Почти все хоткеи работают в зависимости от раскладки. На виндах, когда ещё пользовался ими, такого вообще не встречал; хотя у некоторых стримеров видел эту проблему.
> Но для полного счастья ему нужно сначала выключить физику для каждой части тела, а потом, когда персонаж умирает, включить обратно. Части тела выстроены в иерархию с узлами из ригидбодей, потому что так удобнее анимировать.
Открой для себя группы и не изобретай велосипед. Назначаешь всем частям группу рэгдол, потом вызываешь call_group()
>если у ноды есть потомки, то вызываем, а если нет, то проходим мимо.
Ну смотри. Имеем структуру:
parent
- child
Твой код, на do_work(parent) сделает бессмысленный вложенный вызов do_work(child):
1. func do_work(obj):
2. # можно сделать что-то с объектом вот тут
3. for child in obj.get_children():
4. _ if child.get_child_count() > 0:
5. _ _ do_work(child)
6.
Чтобы попасть на строчку 2, нужно сперва попасть на точку 5 и войти в функцию. Затем будет строчка 3, которая скинет к строчке 6, т.е. выходу. Если вместо этого сделать так:
1. func do_work(obj):
2. for child in obj.get_children():
3. _ # можно сделать что-то с объектом вот тут
4. _ if child.get_child_count() > 0:
5. _ _ do_work(child)
6.
То мы сразу сделаем что-то с объектом на строчке 3, а потом строчка 4 пропустит 5, т.е. лишнего вызова не будет.
Этот код при обращении do_work(parent) просто обработает child и завершится, т.к. у child нет детей.
>Тащемта таких вещей в Годоте полно.
Ну, а должно быть поменьше)
>В линуксе такое повсеместно. Почти все хоткеи работают в зависимости от раскладки. На виндах,
Кстати, некоторые портированные с линукса программы на винде тоже неправильно работают с хоткеями. Скорее всего это недоработка графических компонентов (Qt/GTK), т.к. скан-коды по идее генерируются железом клавиатуры и работает с ними в первую очередь BIOS, а не ОС.
Вот смотри. Вызываем функцию в любом случае извне:
>func _ready():
>_ do_work($node)
1. Теперь оказываемся в функции:
1. func do_work(obj):
2. _ rape(obj)
3. _ for child in obj.get_children():
4. _ _ if child.get_child_count() > 0:
5. _ _ _ do_work(child)
2. Обрабатываем объект
3. Для бездетного объекта всё на этом заканчивается.
4. Опрашиваем каждого потомка, есть ли у него дети. Эту строчку вообще можно было бы пропустить, но у меня в любом случае каждая ветвь заканчивается спрайтом и коллизией, так что бездетную ноду точно не нужно обрабатывать.
5. И только если есть внуки, только тогда переходим к детям.
Твой вариант чище, но есть нюанс.
1. func do_work(obj):
2. _for child in obj.get_children():
3. _ _ # что здесь должно быть: rape(obj) или rape(child)?
4. _ _ if child.get_child_count() > 0:
5. _ _ _ do_work(child)
6.
Если на третьей строчке обрабатывать obj, то он будет обработан много раз. Если же child, то $node так и останется без обработки.
Проверяется очень просто:
func rape(noda):
_ print(noda)
Я проверил, мой вариант работает как надо, без лишних вызовов.
А, ну, для твоего случая имеет смысл сделать так.
Я говорил о таком варианте:
func _ready():
_ freeze_rigids(self)
func freeze_rigids():
_ for child in obj.get_children():
_ _ if child.get_child_count() > 0:
_ _ _ freeze_rigids(child)
_ _ if child is RigidBody:
_ _ _ child.чё_то_там()
То есть на игроке висит этот скрипт, он при старте фризит все ригидбади, которые подвешены на игрока, но самого игрока не фризит (это не нужно/не имеет смысла).
Но как уже выше говорили, это, похоже, нужно решать группами.
Если подумать, то да. В настройках проекта включить borderless window, и per pixel background transparency. В ready включить эту самую транспаренси. Но вот дальше будут реальные сложности, если захочешь чтобы мейты ходили по окошкам программ, то придется написать модуль на c++ и ебаться с голым winapi, скорее всего.
>>657105
А разве нельзя сделать окно на весь экран, чтобы каждый раз оно вырезалось по координатам спрайта? Да, игра по-прежнему не будет видеть чужие окна, но сможет перемещать спрайт по всему экрану.
>>657075
ИМХО, Годо для скринмейта - оверкилл. Скринмейту по сути нужно только выводить спрайтовую анимацию. На каком-нибудь C скринмейт можно уместить в <100 КБ, и это будет не сложнее, чем в Годо. Но да, если хочешь какое-то взаимодействие с окошками - тут только WinAPI...
>А разве нельзя сделать окно на весь экран, чтобы каждый раз оно вырезалось по координатам спрайта?
Не знаю, логичнее выглядит иметь маленькое окно, и двигать уже его. Вроде прозрачность это плохо по производительности, если ты будешь двигать окна программ на фоне то больше перерасчетов делается.
>Годо для скринмейта - оверкилл.
Если заморочиться, можно удобно писать много сложной логики...
>Если заморочиться, можно удобно писать много сложной логики...
Я имею в виду, что для скринмейта ты не используешь и сотой доли возможностей движка. Сложную логику можно писать на любом ЯП, хоть на ассемблере. Движок предоставляет тебе инструменты типа физики, всяких графических штук, интерфейсов и т.д. Тебе же, по сути, нужно только двигать картинку по экрану, меняя кадры. То есть ты будешь иметь 25 МБ кода, которыми не будешь пользоваться, потому что они тебе просто не нужны. Это неправильно.
В принципе, брать движок типа Годо для скринмейта имело бы смысл, если бы скринмейт работал на фреймворке по типу Live2D, со сложной графикой, и имел бы дополнительные части интерфейса (кнопочки, менюшки). Но и то, получается, ты не задействуешь физику и ещё кучу всего (хотя теперь это уже более оправданно).
>Вроде прозрачность это плохо по производительности, если ты будешь двигать окна программ на фоне то больше перерасчетов делается
Если в Годо обрезка окна выполнена так, как я думаю, то ресурсы жрёт создание hRgn для вызова WinAPI-функции SetWindowRgn(hWnd, hRgn, bRedraw): https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowrgn
Проблема в том, что hRgn нужно создавать заново для каждого кадра анимации, если у тебя не статичная картинка. Да, это можно оптимизировать (сохранять hRgn для каждого кадра и переиспользовать), но вряд ли Годо занимается такой оптимизацией. Поэтому вряд ли расширение окна что-то изменит...
>>657153
Да там не сложно, главное осилить концепцию указателей на окно и внимательно читать документацию)
Не то, чтобы это принципиально, смогу и без них, но как-то неприятно.
https://docs.godotengine.org/en/stable/tutorials/misc/pausing_games.html
Держи, пока далеко не ушёл. Пауза для отдельных объектов включается/выключается в один клик.
(просто у меня эта вкладка как раз открыта, чтобы не потерять)
>ты будешь иметь 25 МБ кода, которыми не будешь пользоваться, потому что они тебе просто не нужны. Это неправильно.
Тебе рассказать, сколько в операционной системе на твоём компе заложено возможностей, которыми ты не пользуешься? Универсальные инструменты вообще-то так и работают.
>Что мешает использовать физику для скринмейта? Он может физически точно кидаться чем то.
Ну тогда ок.
>Или навернуть анимаций, частиц, морфинга
Если не ошибаюсь, задать полупрозрачность каждому пикселю окна в Windows невозможно, можно только обрезать окно по пикселям или задать полупрозрачность всего окна целиком (на счёт Aero-тем Windows Vista/7 не знаю). Однако, если это возможно и не требует слишком многого (представляю себе скринмейт, потребляющий 50% ЦПУ), тогда было бы круто.
>>657566
>Тебе рассказать, сколько в операционной системе на твоём компе заложено возможностей, которыми ты не пользуешься?
А я виноват, что вынужден использовать эту ОС и не имею возможности выкинуть эти возможности? После установки Windows приходится удалять часть сервисов и выковыривать часть файлов, которая не будет нужна, но всё лишнее всё равно убрать не получится, это верно. Но ведь нельзя же следовать плохим примерам...
>Универсальные инструменты вообще-то так и работают.
Не всегда. Это Godot скидывает весь свой рантайм в игру, а мог бы скидывать только те части рантайма, которые задействованы конкретным приложением. Да он и файлы из папки проекта все в игру засовывает, даже если они не задействованы никак. Но это проблемы конкретно Godot, а не любого "универсального инструмента".
Кроме того, для некоторых задач рациональнее использовать специальные инструменты вместо универсальных. Те же скринмейты/шимеджи не должны потреблять ресурсы как полноценная игра, это вообще не игра даже. Аналогично, нельзя делать скринсейвер размером с обычную игру - он должен мгновенно запускаться и мгновенно закрываться, иначе у юзера будут проблемы даже на мощном ПК (чем мощнее становится железо, тем медленнее и толще становятся приложения - как раз из-за тех, кто использует "универсальные инструменты" на любой чих, в том числе для создания новых "универсальных инструментов").
>Юзай линукс.
Юзал, не понравилось, вернулся к виндувс. Главный недостаток линукса для меня в его неустойчивости, но это долгая история...
>всё лишнее выпиливается стандартными средствами
Угу, а потом оказывается, что это было не лиш... kernel panic! ...или оставляет после себя как-то непонятные артефакты.
>не сможешь прокрастинировать, играя в игры, вместо того чтобы игры делать
На линуксе тоже игры есть, к тому же моя прокрастинация - это на 99% веб-сёрфинг. Я даже когда собираюсь в игру поиграть, вместо игры в игру прокрастинирую в интернете, в итоге так и не играю ни во что практически, только покупаю. А без интернета ломка.
К тому же вот - >>656909
>Только что проверил на линуксе. Ввод работает только в английской раскладке. Причём и в игре и в редакторе (шоткаты не работают).
То есть на линуксе есть необходимые для геймдева редакторы, но даже они обычно работают кое-как, а альтернатив нет.
В линуксе много проблем, но я от него не отказываюсь.
Кроме того, ты ж для виндовса делаешь игры, поэтому как минимум с вводом в готовом приложении проблем не будет. Я вчера экспортировал демку для ТВГ. В линуксе ввод работает только на английской раскладке, в вайне (и в виндовсе у игроков) ввод уже на обеих раскладках работает.
Я ж грю, линукс не даст тебе расслабиться и прокрастинировать. Это не работает, то недоступно, сё не настроено. Остаётся только писать код.
>ты ж для виндовса делаешь игры
Я ж для себя делаю игры)
>как минимум с вводом в готовом приложении
Да, но работать в редакторе без хоткеев или постоянно переключаться с раскладки на раскладку - лишние трудности. У меня был такой опыт, кажется, в Inkscape - в какой-то из прежних версий хоткеи настраивались для каждой раскладки индивидуально, и это было очень неудобно, прям выбешивало, особенно когда печатаешь русский текст... Потом они это пофиксили, но до сих пор alt+D вместо срабатывания привязанного к хоткею действия почему-то открывает выпадающее меню, и всё это происходит на винде. Короч для разработки нужна стабильная операционная система, и минимум багов среды разработки.
Кстати о багах... У меня в Godot такие проблемы:
1. "Магнитик" в некоторых сценах стал работать по умолчанию, хотя кнопка отжата;
2. Шаг "магнитика" в части сцен 1 метр, в других - 0.1 метра, но я ничего нигде не настраивал;
3. Один раз отвалилась прокрутка кода колёсиком мыши, вообще не понял, с чем было связано;
4. Включение тумана в окружении по умолчанию полностью закрашивает цветом тумана все модельки сцены.
5. Опять же зависание сохранения на 100% сцены с большими инстансами, вряд ли баг, но бесит, явно что-то не то;
6. Export-параметры скриптов в инстанциированных сценах почему-то теряют значение, приходится пересохранять.
Кто-нибудь сталкивался? Может, "ночные" сборки имеют меньше проблем?
Особенно удивило 6, если я задаю параметру новое значение в сцене, приходится вручную сбрасывать все её инстансы в других сценах, несмотря на то, что в них уже лежит, как мне кажется, правильное значение. При этом распространяется не на все инстансы, как будто некоторые некорректно обновляются... фиг знает, то ли я что-то не понял/сломал, то ли баг какой-то, но неудобно, когда инстансов много и по ошибке в логах трудно понять, кто именно виноват.
>"ночные" сборки имеют меньше проблем?
В годоте нет такой сущности, есть мастер который нестабильный, потому что он уже наполовину 4.0 на вулкане. Советую пользоваться стабильным 3.2.1, в него бекпортировали часть фич, и фиксили баги, возможно будет еще 3.2.2 мейтейнс версия.
Курю доки, изучаю примеры, смотрю видеотуторы и пытаюсь понять: а собсно нахуя? У нас есть:
1. Object_A со скриптом отправки сигнала
2. Object_B со скриптом принятия сигнала
3. Динамическая сцена, где создаются разные инстансы Object_A и Object_B.
Чтобы послать сигнал, мне надо сначала соединить два инстанса между собой, а потом послать. Но постойте, а не проще ли написать так:
#где-то в Object_B.gd
func Do_Something():
...
#где-то в Object_A.gd
Instance_Of_Object_B.Do_Something()
В чём выгода от использования сигналов? Для типобезопасности можно дополнительно перед вызовом проверять if Instance_Of_Object_B is Object_B. Пока что я не сталкивался с такими задачами, где такой прямой вызов функций было бы невозможно реализовать.
Не понимаю. Вот у меня есть пули, которые сталкиваются с разрушаемым физическим окружением и персонажами, наносят повреждения, толкают. Обязательно ли тут использовать сигналы? Какие преимущества по сравнению с прямым вызовом функций?
Судя по всему, отключить нельзя. В интернетах народ просит Хуана сделать дополнительный стейт для паузы, для таких случаев. А мне помог как всегда индусский копипаст-код.
В пулях сигналы не нужны.
Сигналы удобны, когда тебе надо дать ноде задачу, подключиться к сигналу готовности этой задачи у этой ноды и пойти дальше. А когда нода сделоет, она пошлёт сигнал. Без сигнала тебе бы пришлось в цикле чекать не выпольнила ли нода задачу.
В программировании сигналы ещё называют событиями, можешь загуглить их. Events.
Ставлю на сцену двух инстансов от одной и той же сцены "человечек" (игрок и враг). Игрока вкладываю в ноду Control, которая передаёт сигналы с клавиатуры как команды своему человечку-потомку. Внутри сцены "человечек" нет ни одного обращения к каким-либо нодам за пределами сцены. Тем не менее, когда я нажимаю прыжок, игрок подпрыгивает нормальным образом, а враг слегка дёргается в направлении прижка. Магия какая-то.
Да всё, проехали.
Проблема ушла после переименования ноды игрока. Её имя совпадало с именем класса. Через это каким-то образом пролез AnimationPlayer и попытался проанимировать тушку врага; но у того был свой AnimationPlayer, который сопротивлялся, отыгрывая idle.
Такие дела. Вывод: лучше всегда переименовывать ноды, чтобы имя не совпадало с именем класса.
Хотел попробовать годот. И скачал при выборе с шарпом. Но годот сам кричит, что шарп там говно альфа, все по ишью, все по тому сему. Если действительно так плохо, то пока не поздно перейду на питоноподобный гдскрипт. Хотелось бы не переходить конечно (я по работе на питоне сижу и искренне его ненавижу уже), но если шарп и правда работает примерно нихуя, то лучше бы узнать об этом сейчас.
> если шарп и правда работает примерно нихуя, то лучше бы узнать об этом сейчас
Шарп работает. Поддерживаются все АПИ. Просто в редакторе реализация шарпа скудная. Когда я смотрел крайний раз, не было интеллисенса. Просто открываешь проект в студии и пишешь в ней, не забывая сохраняться, перед переключением в редактор годота.
>>658353
Эта хуйня называется невнимательность.
Пробовал, в основном разница в том, что приходится сидеть и угадывать в какой нотации записано имя метода или проперти. Вот тут я должен был догадаться, что basis пишется с маленькой, хотя обычно все поля типа Visible пишутся с большой. Поэтому документацией пользоваться довольно неудобно. Как и примерами кода. Даже кто то сайт запилил чтобы смотреть апи https://godotsharp.net/api/3.2.0/
В текущем проекте менять уже не буду, хочу чтобы он работал со стандартным годотом с оф сайта, дальше посмотрю. Хотя меня по прежнему больше соблазняет идея писать прямо на плюсах. И никакой зависимости от моно.
>>658370
>Шарп работает.
В айфонах еще только в планах добавить в стабильную ветку:
>Godot 4.0 will be getting C# support for iOS. We also plan to include it in a 3.2.x release, which could be 3.2.2 if everything goes well.
Не уверен что в WebAssembly экспорте уже доделали AOT-компилятор. Если нет, то там будет ооочень медленно.
Экспорт mono на Андроид не так давно сделали, неизвестно как там по багам.
>Вот тут я должен был догадаться, что basis пишется с маленькой, хотя обычно все поля типа Visible пишутся с большой.
Пик отлепился
Так скрин старый был где то, думаю не сильно поменялось. Но поскольку писать так медленнее (писать на плюсах в принципе медленнее, плюс надо ждать каждый запуск линковку), то прототипировать я продолжил на гдскрипте. Как можно заметить там тоже придется угадывать апи, например вместо basis.z там basis[2].
По поводу туториала, в целом, там создается обычный cpp модуль по инструкции с оф сайта, а в объявлениях своих классов пишется что то вроде макроса GDCLASS(YourClassName, BaseClass) и обработчик _notification(int) который дергает my_ready(), my_process(delta) и my_physics_process(delta). Собственно весь мой утилитный класс на пик2. Он включает в себя дебажный вывод, проверку на работу в редакторе/в релизе, саму рыбу для класса, и пару сокращателей для поиска ноды и каста типов.
Использование примерно показано на пик3, из значимого - в объявлении класса надо написать упомянутый макрос, новые объекты с подсчетом ссылок надо создавать через memnew(ClassName), сигналы работают как обычно, только надо регистрировать обработчик через bind_method(...)
>>658384 (OP) (OP)
>>658384 (OP) (OP)
>>658384 (OP) (OP)