Шапка: https://hipolink.me/godothread
Предыдущий: >>1022039 (OP)
Архивный: >>1017767 (OP)
Только в ламбе синего цвета, заработанной на годот игрульках
>А она даст мне писечку полизать, если я игру сделаю?
Так создание игры на годоте это и есть лизание писечки годот тян. Представь что ты хочешь ее удовлетворить, часами лижешь и лижешь. Она то возбуждается то опять остывает. Твоя задача раскачать ее писечку до такой чувствительности чтобы довести ее до двухчасового тантрического оргазма. Задача для настоящего симпа годот тян. Но если научится хорошо владеть языком и пальцами, и выучить все ее эрогенные зоны, то однозначно выполнимая задача.
>Попробуй
Пробовал ещё лет десять назад. Штука отличная, но я всё-таки в сторону геймдева хочу развиваться. А в геймдеве Dear ImGui - практически индустриальный стадарт. И вообще ни одной игры не знаю, которая бы разрабатывалась на диалектах Паскаля.
>Так создание игры на годоте это и есть лизание писечки годот тян.
Странно. Я думал создание игр на годоте это скакание на дилдаке из серии Bad Dragon.
Ресурс один, все сцены ссылаются на него. В последней отредачил - заменил везде. Да и не заменил, а по ссылке в следующий раз откроется отредаченное. Чтобы этого избежать, как тебе показали скрином выше, следует вручную нажать галку, которая сделает ресурс локальным.
Суть ресурсов именно в этом, чтобы они в единственном виде существовали, и по ссылке передавались на единственный экземпляр.
О, кстати, ресурсы - это синглтоны.
Алсо, еще можно ПКМ по ресурсу (в данном случае материалу) и "make unique". А вообще рекомендую сохранять ресурсы с осмысленными названиями и по возможности переиспользовать их, а не городить свое на каждый объект.
>О, кстати, ресурсы - это синглтоны.
Теперь надо написать доклад на тему почему это плохо.
Возможно, у тебя какой-то не такой воркфлоу, обычно модельки не редактируют в движке, а только импортируют из например блендера.
Во-первых это не проблема воркфлоу, это фича движка - передавать ресурсы по ссылке и не дублировать их без явного запроса. Во-вторых делать материалы сразу в движке - полностью норма. У меня например 3д с большим зумом, и простые модельки я могу с помощью CSG наклепать прямо в движке, перегнать в меш, накликать базовый материал и норм - хуй там кто чего разглядит. Запускаю 3д редактор только для чего-то сложного, текстурированного, анимированого.
Просто мой глаз зацепился за то, с чем давно не сталкивался, поэтому подозреваю там какую то ловушку новчика, типа дублировать всю сцену персонажа и в результате иметь 5 вариантов одного и того же персонажа с разным альбедо, вместо просто замены материала.
Ну чё, имба или не?
https://www.reddit.com/r/godot/comments/1lg0t11/this_is_ndb_indiehorror_game/
А то жаловались дескать игр-то нет.
Полистал собстна этот редит по годоте. И чет ахуел. Чому там все засрану вылизаными 2д играми то? Разве наш годот не движок для шизофреников?
Не, анончик, я не настолько прям новичок, чтобы о такие вещи спотыкаться. У меня есть оригинальная сцена нескольких айтемов, они у игрока есть по умолчанию и потому подгружаются сразу после перехода с главного меню и больше никуда не деваются и не дублируются. Я албеду накинул просто потому-что у меня модельки из блендера а колор-рамп из него почему-то не экспортируется в .glb (во всяком случае у меня). (а запекать текстуры и всю эту хуйню я не умею) Потому я подкручиваю цвет альбедой. Уже в привычку вошло. Так вот, прикол даже не в самой игре, как таковой. Я могу в сцене покрутить цвет, сохранить сцену (материал не сохранен в файл) и перезайти в движок. После этого альбедо опять сбрасывается везде, кроме последнего редактированного меша. То есть выглядит эта ситуация, будто баг в самом редакторе.
> Vertex Block Descent — это быстрый метод моделирования на основе физики, который безусловно стабилен, хорошо поддается параллелизации и способен сходиться к неявному решению Эйлера. Мы расширяем его с помощью расширенной лагранжевой формулировки, чтобы устранить некоторые из его фундаментальных ограничений. Во-первых, мы вводим механизм для обработки жестких ограничений с бесконечной жесткостью без введения числовых нестабильностей. Во-вторых, мы существенно улучшаем сходимость при наличии высоких коэффициентов жесткости. Эти изменения, которые мы вводим, позволяют моделировать сложные контактные сценарии, включающие жесткие тела с укладкой и трением, сочлененные тела, соединенные жесткими ограничениями, включая суставы с ограниченными степенями свободы, и жесткие системы, взаимодействующие с мягкими телами. Мы представляем оценки с использованием параллельной реализации на GPU, которая может обеспечить производительность в реальном времени и стабильное моделирование с низким числом итераций для миллионов объектов, взаимодействующих посредством столкновений, различных ограничений суставов/креплений и пружин различной жесткости. Наши результаты показывают превосходную производительность, сходимость и устойчивость по сравнению с современными альтернативами.
https://www.youtube.com/watch?v=bwJgifqvd5M
ВЕЧЕРОМ ДЕНЬГИ - УТРОМ КОД! ИЛИ НАОБОРОТ - УТРОМ ДЕНЬГИ - ВЕЧЕРОМ КОД!
>Теперь надо написать доклад на тему почему это плохо.
Ну так а вдруг ты внезапно захочешь мультиплеер?
>>1027067
Если бы можно сделать шрифт ещё мельче, ты бы сделал, да?
>>1027065
Попробуй отконвертировать материал в шейдер. Ну так, мало ли.
Можно ещё попробовать в исходниках годота сделать grep albedo, но я вангую, что там ничего специфического не найдёшь. Скорее всего, проблема где-то в файлах сцен. Странно было бы, если бы к одному ресурсу было особенное отношение в исходниках.
>Descent
Дау угадаю, основан на поиске чисельной производной и добавлением получившегося вектора вниз с теми же проблемами.
>ImGui - практически индустриальный стандарт.
Странно, обычно же используют Qt или GTK+?
Но кто-то написал биндинги и под Паскаль:
https://github.com/Coldzer0/ImGui-Pascal
https://forum.lazarus.freepascal.org/index.php?topic=65187.0
>игры не знаю... на диалектах Паскаля
Большинство в 90-х/00-х, потом Unity появилась...
https://wiki.freepascal.org/Games
https://wiki.freepascal.org/Projects_using_Lazarus_-_Games
https://web.archive.org/web/20210516110900/https://www.pascalgamedevelopment.com/showthread.php?4519-The-great-list-of-Pascal-Games
https://castle-engine.io/gallery_games.php
Было много движков, Castle более-менее живой.
Печально, что опенсурс движки так часто умирают.
Давно собирался попробовать Castle, но после Godot возиться с чем-то не упакованным в один EXE как-то желания нет. Godot удобен тем, что его можно просто запустить и сразу что-то делать, не читая туториалы, приблизительно как тот же Lazarus/Delphi.
ОП, извини, что не совсем по теме.
>Странно, обычно же используют Qt или GTK+?
В где угодно - да. А в игровой индустрии - https://github.com/ocornut/imgui/wiki/Software-using-dear-imgui
Тот же QT претендует на главный цикл приложения, насчёт GTK не знаю, но вроде тоже. А в главном цикле у всех нормальных игровых движков вообще-то движок. Плюс эту штуковину можно прямо в проект добавить, у неё зависимостей ноль ну, кроме графических фреймворков; ну так их движок за собой тащит в любом случае.
>Печально, что опенсурс движки так часто умирают.
Во-первых, easy cum easy go.
Во-вторых, проприетарные движки умирают точно так же, просто это отследить сложнее.
В-третьих, то была эпоха, когда у каждой дворовой собаки был свой игровой движок. А сейчас написать свой движок становится всё сложнее и сложнее, особенно если хочется современных технологий и вылкана, зато готовеньких полно на любой вкус.
А вообще, шо тебе дался этот паскаль? Я понимаю, что игры на чём угодно пишут, хоть на редстоуне. Но так-то в целом паскаль не для этого.
А вообще, благородный дон, если желаете продолжить беседу, предлагаю перейти в отдельный тред.
>перейти в отдельный тред
Так я сижу на Godot >5 лет уже...
>шо тебе дался этот паскаль?
Синдром утёнка.
Если серьёзно, потомки Pascal занимают интересную промежуточную нишу, аналогов которой я не нашёл. Потенциально полезно в контексте Godot:
- моментальная компиляция, в отличие от долго собирающегося C/C++/C# и их разновидностей;
- относительно высокая производительность, т.е. приблизительно на уровне C#, чуть похуже C++ (т.к. оптимизировать код в один проход очень сложно);
- отсутствует GC - лучше подходит для игр, чем C#;
- читабельность кода выше, поскольку вместо спецсимволов и сокращений - полные слова;
- нативный код без виртуальной машины, т.е. можно линковать с кодом на C/C++, т.е. в теории возможно написать свой Godot-модуль на Pascal, а не просто прилепить снаружи через GDNative/GDExtension;
- относительно популярен, в отличие от уже совсем забытых языков и совсем недавно придуманных.
Вкратце, это альтернатива C++, но без критических недостатков C#, Rust и прочих "как C, но не C". Все недостатки сводятся к "дольше печатать", но кого это волнует в эпоху генерации кода нейронками, лол. А читать-то лучше длинные слова, чем {крякозябры()::}, восприятие мозга лучше всего работает со словами.
>ресурсы - это синглтоны
Кто тебе это сказал? Синглтон - это класс, у которого:
- может существовать только один экземпляр;
- доступ глобально по уникальному имени.
А что у Resource?
- можно создать любое количество экземпляров;
- нет глобального доступа по имени, т.е. локальны.
Сцены используют общие ресурсы, но это не имеет абсолютно никакой связи с паттерном "синглтон". Использование общих ресурсов - это просто ссылки (указатели, pointer) на конкретный экземпляр класса.
>>1026984
>модельки не редактируют в движке
Материалы обычно в движке редактируются, т.к. у Блендера свой собственный рендерер, он не точно соответствует рендереру Godot, плюс шейдеры ты можешь писать только на языке Godot.
>>1026988
>3д с большим зумом
>CSG наклепать прямо в движке
CSG часто делает тонкие и вытянутые треугольники. Разницу на ПК вряд ли заметишь, но на мобильных устройствах это критический недостаток CSG мешей.
>>1027065
Как ты используешь импортированные glb?
1. Создаёшь новую сцену-потомка glb и сохраняешь отдельно в виде сцены tscn?
2. Добавляешь glb сцену в сцену tscn и выбираешь редактирование вложенных нод?
Я лично сталкивался с проблемами сцен-потомков неоднократно, особенно когда импортирую новую модельку вместо старой. Поэтому использую второй метод, он кажется более надёжным (но не всегда).
Также рекомендую сохранить все свои материалы в отдельные tres файлы и соединять их к моделям по необходимости, а не редактировать внутри моделей. Потому что так меньше риск потерять настройки.
Аналогично с любыми другими ресурсами, у которых имеется много полей или много данных в одном поле.
Берёшь код (тянучка писала?!):
https://github.com/AnkaChan/Gaia
Добавляешь в движок по гайду:
https://docs.godotengine.org/en/stable/contributing/development/core_and_modules/custom_modules_in_cpp.html
Только зачем? Тебе мягкие тела в игре нужны?
>Когда в Годот завезут?
Официально - никогда: там CUDA в зависимостях.
Придумал крч огромную area на весь уровень, и так на каждом уровне, и этой ареа выставил только подозрительный слой. Ничего не нашлось. Видимо не использовал.
Напиши какой нибудь тул скрипт или просто скрипт. Который рекурсивно обходит все ноды. Что нибудь по типу https://www.reddit.com/r/godot/comments/40cm3w/looping_through_all_children_and_subchildren_of_a/
И там что-то вроде if "collision_layer" in node: if node.collision_layer & YOUR_LAYER: print("бабах")
Да, если отказаться от физики жидкостей и частиц заменив ее другими штуками попроще, например разрушаемость как в червяках сделать, но раз ты спрашиваешь то ты не осилишь
github.com/godotengine/godot-proposals/issues/2972
Ебанный позор
По итогу полное ощущение что получается говнокод, который тяжело читать, легко сломать и невозможно масштабировать. Каких материалов анонимус советует покурить, чтобы набраться скилла в этом направлении?
>Да, если отказаться от физики жидкостей и частиц заменив ее другими штуками попроще
А в чем проблема физики жидкостей в годоте?
Мимо
Можно как вариант на расте.
Жаль раст пока что почти не юзают в игровой разработке.
Да, готовся забыть про ноды и само существование такого понятия как нода для игровых объектов. PhysicServer для тебя не существует и заменяется на Dummy, отныне RenderingService - всё что для тебя существует. Про c# забывай, и пути у тебя два - либо писать всю игру на gdextension (то есть на плюсах) либо на gds. Соответственно только годот4, гд3 отпадает. gdextension тебе всё равно потребуется чтобы писать максимально облегченную физику. Если совсем коротко - придется практически всё кроме системы ресурсов и интерфейса делать за движок вплоть до его непосредственного редактирования (движка). У этого будут и свои плюсы, типа того что если ты удачно встроишься в движок - получишь все его блага (мультиплатформа, готовый язык шейдеров и в частности compute шейдеров) - но придется прям непосредственно знакомиться с темной стороной годота. Сумеешь - выиграешь большой объем бонусов. Не сумеешь - будет неприятно и проебано много времени.
Она требует определённой оптимизации, которую gdscript не даст, да даже голый C++ без определённых знаний не даст с нормальным FPS эмулировать столько частиц
Ну я же не ньюфаг, всё сделано, как всегда, а игры в ленте и поиске сайта нету
> готовся забыть про ноды
С чего бы?
А почему нельзя написать игру на gdextension (то есть на плюсах) которая будет представлена единственной нодой, которую он затем выложит на стартовую сцену и к ней добавит гуй на зелёных нодах?
Мне обязательно надо обьяснять почему это не будет игровой сценой базирующейся на нодах?
В нойте и нет физики жидкости, там как раз заменили на попроще.
Если бы я сказал только о физике частиц, это могло быть не понятно, можно дальше не доёбываться, отдельная обработка частиц жидкости в ней есть
Я читал что это обычное дело, она может попасть в очередь на ручную модерацию, и вообще официальный ответ итча у нас выходят тысячи игр, не рассчитывайте на ленту, раскручивайтесь сами.
Это симулятор сыпучих пикселей, к которому добавили пару правил для покачивания волн, но не добавили рассчет давления или векторы течения.
Вывод - если в нойте отказались от симуляции жидкости, то и в твоей игре на годоте ты можешь спокойно отказаться. Можешь начинать делать игру на годоте.
>Соответственно только годот4, гд3 отпадает.
В гд3 есть GDNative, а так же модули движка, поэтому проблемы писать на c++ нет. Вот для чего может быть смысл брать гд4, это компьют шейдеры. Но на них написать такую игру может оказаться сложно, потому что она плохо параллелиться (вычисления зависят от соседних пикселей, а для распараллеливания лучше независимые).
> рассчет давления
P.s. это нужно для сообщающихся сосудов (communicating vessels), которые в нойте не симулируются.
>Жаль раст пока что почти не юзают в игровой разработке.
Bevy вполне себе взлетел. Регулярно вижу про него посты в своей ленте, и про игры на нем. Вот эта охуительная штука на Беви/Расте, посмотри как там билдится на лету: https://store.steampowered.com/app/2198150/Tiny_Glade/
Вот что не взлетело для геймдева, так это Го. Было полтора движка от васянов, один из них умер, другой чисто 2д. Хотя как язык норм, живой-популярный.
Я кстати до вката в геймдев думал что Godot это движок на Go, лул.
Не "взлетел", а там тянка натужно форсила себя в твиттере. Геймплей то туда так и не завезли.
>от эта охуительная штука на Беви/Расте
https://www.youtube.com/watch?v=jusWW2pPnA0
Если переходить на тройку (кстати - зачем? Непременно нужно легаси? И лагающий 2 опенгл?) - то от гдс придется отказаться впринципе и делать игру на плюсах полностью, хотя я бы например логику и управление нпс писал бы на гдс, так попроще и гдс в 4 годоте нормально прикручен к движку, а в с++ выносил только реально тяжеловесное. Можно конечно вообще всё на с++, но можно и не всё. Компьют шейдеры помогут считать физику жидкости, так что их бы тоже оставить. Гднатив это вообще другого поля ягода, использовать его для подключения плюсов это всё равно что ковыряться в двигателе через выхлопную трубу, потому как оверхед у него смертельный для производительности, так что только c++ модули либо прямое редактирование движка, что по сути своей одно и то же, так как придется ребилдить движок раз за разом. Почему гднатив говно можно узнать тут https://sampruden.github.io/posts/godot-is-not-the-new-unity/ и с момента публикации статьи ситуация лучше не стала.
Там нюфаг не разобрался и потом бегал с извенениями, что все напутал.
Между GDNative и модулями с точки зрения программирования нет практически никакой разницы, поэтому разрабатываешь быстрыми итерациями используя GDNative и перекомпилируя только свою легковесную длл, а когда дело будет к релизу, пересобираешь уже как модуль, делать это надо будет редко.
Про оверхед, звучит голословно, продемонстрируй бенчмарки.
>Между GDNative и модулями с точки зрения программирования нет практически никакой разницы
Не разрабатывал, не знаю, но это звучит бредово, потому что гднатив это апи к движку, которое имеет собственный оверхед на то чтобы преобразовывать внутренние типы в то что можно отдать по апи и лучшей иллюстрацией тому является данная мной ссылка выше, где в секции рейкаста результат упаковывается не в структуру, не в обьект, а в словарь в куче из variant с ключами в виде строк. Насколько я помню гднатив не позволяет вызывать методы движка, не вынесенные в заголовочные файлы под гднатив, а значит нужно будет каждый такой "тяжелый" вызов засовывать в макросы с вариантом для игры как модуля и для игры как гднатив.
Да, собрали свой суповой набор, в том числе и из кусков беви, но это не то же самое что просто взять беви, там сдф реймаршинг, поэтому важна тут первая строчка в первую очередь, о рендере, в терминах годот ближайшей аналогией будет использование огромного компут шейдера который будет делать 99% работы. Ну, а если ты в состоянии собрать свой движок из кусков существующих, то смысла гоняться за растом/беви - нет, в смысле они не облегчают сильно работу, просто инструмент.
>Не разрабатывал, не знаю, но
Ну вот а я разрабатывал и знаю.
>где в секции рейкаста результат упаковывается не в структуру, не в обьект, а в словарь в куче из variant с ключами в виде строк
Пример по твоей ссылке показывают работу с GDNative на C, если откроешь пример на C для GDExtention там будет такой же пезденящий дущу леденец
https://store-beta.godotengine.org
Правда открывается у меня только через впню
Как мне принудительно вызвать _get_drag_data?
В том плане, что у меня есть инвентарь со слотами. У каждого слота есть _get_drag_data, которая автоматом отслеживает нажатие и начинает перетаскивание предметов.
Но как его вызвать принудительно? Вот допустим я у слота вызываю контекстное меню и там кнопка "разделить", после нажатия на которую у меня должно сразу срабатывать перетаскивание.
Или легче будет вообще забить на строенные функции и просто самому запилить систему менеджмента инвентаря с чем-то вроде slot_rect.has_point(mouse_position)?
Ощущение, что для гибкой настройки _get_drag_data не очень то подходит либо я криворукий
Да-да, уже готовлюсь продавать эту вашу Хоппу.
Нормально все. Учитывая что почти все плагины к годоту опенсорсные это по сути способ удобно задонатить разработчикам плагинов. Ну и удобно скачать/найти нужное.
Ты же ныл до этого что плохо когда нет профессиональных ассетов решающих сложные задачи. Переобулся?
Там упомянута функция force_drag, она вроде принудительно заставляет объект таскаться даже если на него не кликнули.
Даже не знаю, с чего ты решил, что это был я. Какая-то попытка на ярость?!
>нельзя даже сделать интерфейс который скейлится от размера окна без написания костылей
Хехмда
То что ты считаешь костылями, настоящие кодеры считают свободой самовыражения. Они могут так написать, а могут эдак написать. И в целом они могут написать, а ты не можешь. Ты можешь только у чат-бота запрашивать код, получать портянку, не глядя компилировать, а потом жаловаться на костыли. Что не так? Не так? А?
Короч, надо кубики в 3D и чтобы их таскать мона было мышкой и настраивать кубики, и чтобы не запариваться с нуля - долго и сложно.
Я видел что-то похожее лет 5 назад, и очевидно для трёшки. Гугли.
>>1027563
Не уверен что такие материалы найдутся. Просто опыт, смотри как что делают другие (хотя зачастую там будет тот самый не масштибируемый говнокод, зато он будет работать)
Ну ладно, хелпаю. Это называется дайс, и оно есть реализованное. Пикрелейтед. Дальше сам.
Анонимус, помни - сигналы - это просто заплатка прикрывающая дерьмовую архитектуру. Они очень просты, выглядят легко, казалось бы - надо чтобы одна ветка программы заставила другую её ветку сделать что-то, что другая ветка сама по себе бы и не собиралась делать. Но в этот момент ты на ровном месте формируешь сайд-эффект, который неформально в рантайме связывает то, что связанным быть никак не должно, это даже хуже чем синглтон, его зависимости хотябы отслеживаемы.
У карт есть обладатель, у обладателя есть level/session controller, у level/session controller есть gamecontainer в рамках которого игровая сессия имеет уникальный ид. Взаимодействие карт происходит через статический код, куда передается набор обладателей карт, взаимодействующих в данный момент, над ними производятся вычисления, вызываются методы обновления переданных в этот статический код обьектов и так происходит игровой процесс взаимодействия карт. Если карта сама по себе пожелает что-то сделать (что тупо но допустим) - она обращается к владельцу, владелец вызывает контроллер сессии и вновь происходит групповая операция. Каждый элемент легко протестировать, синглтоном является только энтрипоинт в сессию, можешь подучить dependency injection для облегчения проброса зависимостей вглубь веток. Программа должна быть похожа либо на дерево, либо на одноуровневое горизонтальное поле пшеницы(данных) по которому ездит исполняемый трактор (или много тракторов)
> Анонимус, помни - сигналы - это просто
Сигналы это ивенты. Сигналами ивенты впервые назвали в GTK, чтобы не как в винде. Дальше не читал бред мультикнопочникотона.
У них много названий. Суть одна и та же - инкапсуляция призыва к действию получател(я/ей) этого сигнала, к действию которое вызывается никак иначе кроме как этим сигналом. При взаимодействии двух и более программ формирование единого апи для каждой программы в отдельности еще хоть как-то оправдано, но в рамках 1 программы - это лучший способ расстрелять себе ногу. А самое веселье наступит в момент когда события начнут провоцировать другие события, говорю по опыту разбора такого "программного продукта".
Ну в годоте можно без сигналов.
>>1027601
> Программа должна быть похожа либо на дерево
Чек. Программа уже похожа на дереве. Просто управляешь любыми нодами из корневого скрипта. А что не так? А что такое?
"Не так" - проброс сигнала из карт в корень. Это значит что отсутствует прямая вертикальная связь с корнем программы и карты живут сами по себе в своем мире.
Причем тут сигналы? Я тебе говорю, управляешь всеми нодами из корня. Всё. Никаких сигналов.
Ты мимокрок? Поднимись по треду и рассмотри кому изначально я адресовал свое мнение про вредность сигналов. Вот это:
>>1027601
Вот ему:
>>1027286
Ну пока он не вернулся, я и законтрил твой вредный совет с охуительными историями про вред сигналов.
База. Пост approved by бывший менеджер из АА-конторы, который за best practice и против синглтонов.
Сигналы мощная и гибкая вещь, но на отъебись ими пользоваться не получится, нужно делать к ним устойчивую архитектуру на стейт машинах, уметь отбрасывать уже невалидные события прилетевшие после смены стейта. Вот сколько мне присылали последних проектов на проверку, у всех одни и те же баги - например у кого то меню зависает и остается на экране когда уже игра идет, у кого-то после выигрыша может прилететь тик урона и одновременно показать надпись проигрыш.
Ну и конечно с сигналами надо быть вдвое внимательнее, чем с функциями, чтобы не отправлять сигнал который никто не ловит, и наоборот ловить сигналы, которые никто не отправляет. В моей иерархии сигналы где-то посередине между нормальными функциями и вызовом "по строке", которая вообще ненадежная как карточный домик.
Твой вредный контр отменен и перекрыт двумя полезными историями про вред сигналов.
Там кстати на днях еще один десятилетний мегастрой наебнулся. Не помогли ни многомиллионные инвестиции от Riot Games, ни выкуп ими всей компании, ни награды авансом. Зато пару раз с нуля успели движок переписать, переделать всю архитектуру, и скоп крип такой заебенить что сами охуели. При этом ни одной публичной версии так и не выпустили, в отличии майнкрафта, играбельного буквально с пустых кубов. "Либо релизнем полную и идеальную 100/10 игру, либо ничего, никаких компромиссов, ничего не вырежем, у нас же гениальный ВИЖН".
Шизка и понты точь-в-точь как у кое-кого из местных ноудевов.
На самом деле нормально написанная игра позволяет себя переключать в оффлайн/онлайн по желанию пятки, да. А ecs так и вовсе позволяет за дни мерджить серверную логику с клиентской и датамодель сервера с датамоделью клиента. Хотя конечно не бесплатно, давать такое вкатуну бесполезная трата времени. Но ты скорее всего либо безыгорка либо джем энжоер, поскольку даже не понимаешь сути проблемы которую формируют сигналы и почему сайд эффекты (в частности неуправляемые сайд эффекты - их появление зависит текущего от состояния приложения) так опасны для конечного продукта.
Не отвлекайся, тебе там архитектуру мультиплеерных кнопок на передел привезли, снова. Говорят у них серверная датамодель не та.
>Это типа советы как проебать годы и нихуя не сделать?
Это тебе к синглтонщику. У него много антипрактик.
Не, это мне к тебе, маневрятор. Сейчас наймем манагера из а-конторы и будем под его гениальным хлыстом лет 10 яйца вылизывать. Может на том свете зачтется.
Ты меня с каким-то шизиком перепутал. Мультиплеерная кнопка это плод болезной фантазии больного RPC головного мозга. Которые кстати тоже частный случай событий. Интерфейс отдельно, шина сетевых событий отдельно, игровые сущности в рамках контейнера игровой сессии отдельно, ui элементы связанные с игровыми сущностями живут в контейнерах, которые им предоставляет интерфейс. Соответственно любая кнопка появление которой приходит из игровой сессии живет пока жива игровая сессия и обычно появляется не по мановению rpc, а по клиентской реакции на изменение датамодели из сервера. Ладно, понесло меня уже.
Мультиплеерная кнопка вообще не про годот, это про фундаментальное ограничение современной винды.
Тогда тебе придется поторопиться, потому что у меня на днях два собеса и ты уже будешь третьим в очереди.
За пару дней в двух местах успеешь поработать и снова оказаться на улице? Талантище. Мы вам перезвоним.
Гугл Джемини скрипт написал, куб видно, но он стоит, ошибок не видно.
Влияет. Форма должна быть чайлдом физического объекта (например RigidBody или CharacterBody), а ты прикрепил к визуальному мешу.
Смотря как ты собираешься двигать свой куб. Коллижн шейп нужен чтобы придать физическую коллизию Area/Rigid/Character/Static телам. А у тебя шейп находится внутри меша, меш это просто графический 3д объект.
Попробуй такую структуру:
- Area
-- CollisionShape
-- MeshInstance
Тогда, если твой вайбкод jcbkbn, Area должно задетектить коллизию (ray_pickable) используя форму заданную с помощью CollisionShape, и сдвинуться с места, а вместе с ним и его дети - меш и коллижн шейп.
Чет челик тут пишет сделал и слишком сложно настраивать, под каждую сцену придется.
>>1027705
У меня всё норм там или не?
Чёт скрипты от Гугл Джемини теперь ошибки вызывают.
>разраб не осилил создание списка в 1 строчку?
Что значит "не осилил"? Про кого ты говоришь?
Ненужно. Разберешь, а потом опять собирать взад вперед, вместо этого учись пользоваться map/reduce
>мегастрой наебнулся
Ничего, свой на Godot запилим!
https://reddit.com/r/HytaleInfo/comments/1ljd3ic/comment/mziuaic/
>кое-кого из местных ноудевов
Обидно вообще-то...
Нужен интерфейс Steamworks SDK:
https://partner.steamgames.com/doc/home
Есть готовые бесплатные ассеты, но я не пробовал:
https://godotengine.org/asset-library/asset?filter=Steam
https://github.com/GodotSteam/GodotSteam
Не взлетит, надо было Худот вместо Готейл.
>Обидно
Да лан, я любя. Тред любви же.
> за 4 года разраб не осилил создание списка в 1 строчку?
> github.com/godotengine/godot-proposals/issues/2972
Эмм... А это как?
>Вот допустим при наведении на карту она должна выделяться. Сделать для этого функцию в скрипте карты? Но тогда она будет срабатывать каждый раз без оглядки на окружающую ситуацию.
В чём проблема? Какая "ситуация" может мешать подсвечиванию карты в карточных играх? Лучше беспокоился бы о том, кто руководит движением.
>Запихнуть код в корень сцены? Тогда придётся тянуть от карт сигналы через всё дерево сцены.
Зачем "через всё дерево"? Можно так, например:
>card.tscn, card.gd: # отдельная сцена
>class_name Card extends Area2D
>signal selected(card: Card) # мышкой, клавиатурой...
>card_manager.gd: # отдельная сцена
>class_name CardManager extends Node2D
>var selected_card: Card
>func _on_card_selected(card: Card) -> void:
>_ selected_card.highlight = false
>_ card.highlight = true
>_ selected_card = card
Игровая сцена:
>Game: Game
>- Background: Sprite
>- Table: CardManager
>- - Card: Card
>- PlayerHand: CardManager
>- - Card: Card
>- EnemyHand: CardManager
>- - Card: Card
И т.д.
> Вот допустим при наведении на карту она должна выделяться.
обрабатываем вход/выход мыши
> Но тогда она будет срабатывать каждый раз без оглядки на окружающую ситуацию
Заводим стейт-машину картам и задаём им стейт(ы) при котором(ых) карты реагируют на мышь (на инпут).
Ваще большинство проблем геймдева решается стейт-машиной. Кроме проблемы взрыва стейтов при заведении стейт-машины. Она решается заведением второй стейт-машины.
>сигналы - это просто заплатка
Сигналы/события - это EDA, event-driven architecture. Чрезвычайно полезная вещь, избавляющая тебя от непрерывного запроса состояния других объектов.
>надо чтобы одна ветка программы заставила другую её ветку сделать что-то, что другая ветка сама по себе бы и не собиралась делать
Ты совершенно не понимаешь концепцию событий. События возникают внутри объекта и оповещают об изменении состояния объекта внешний мир, но не заставляют кого-либо реагировать на них.
>ты на ровном месте формируешь сайд-эффект, который неформально в рантайме связывает то, что связанным быть никак не должно
Во-первых, EDA отличается тем, что максимально отвязывает объекты друг от друга. Связывания не происходит, происходит лишь реакция на события.
Во-вторых, ты делаешь это осознанно - по плану.
>синглтон, его зависимости хотябы отслеживаемы
Синглтон - это глобальная сущность, которую можно вызывать из любого участка кода, поэтому синглтон максимально связывает твой код, превращая всё приложение в непонятную лапшу из зависимостей. Аккуратно им пользоваться сложнее, чем сделать аккуратную архитектуру на событиях (сигналах).
>Программа должна быть похожа на дерево
Да, именно поэтому нужно использовать сигналы.
>одноуровневое горизонтальное поле данных
Это противоречит ООП, т.е. усложняет поддержку.
>>1027608
>Суть одна - инкапсуляция призыва к действию получател(я/ей) этого сигнала, к действию которое вызывается никак иначе кроме как этим сигналом.
Ты не понимаешь сути событий. Позволь объяснить.
Но начнём с базовых концепций:
Переменная/объект: что мы ИМЕЕМ?
Функция/метод: что мы СДЕЛАЕМ?
Событие/сигнал: что ПРОИЗОШЛО?
Пример:
Человек - это объект.
Идти - это действие объекта.
Упал - это изменение состояния.
Если нам нужно что-то, мы берём объект.
Если нужно что-то сделать - вызываем метод.
Если нужно узнать о том, что может произойти в будущем - мы берём объект и подписываем один из собственных (или чужих) методов на событие, что объявляется выбранным нами объектом.
Проблема возникает из-за непонимания того, что случившееся событие - это не призыв к действию, а оповещение о том, что какое-то действие совершено. Событие никого ни к чему не принуждает, и тебя, как разработчика объекта, совершенно не волнует, кто в будущем может отреагировать на твоё событие. Но выставить событие наружу ты должен, если по плану необходимо знать о том, что что-то где-то произошло.
Пример роли событий из реальной игры: YandereDev заставлял NPC в Yandere Simulator проверять 60 раз в секунду игровые часы, чтобы узнать, не пора ли NPC проследовать в кабинет на урок. Понятно, что для 10 подобных NPC получается уже 600 запросов каждую секунду, на протяжении всей игры. Как решить эту проблему? Игровые часы должны иметь событие "начинается урок (математики, физики и т.д.)", а NPC - подписываться на событие часов, например, так:
>func _on_clock_class_starts(class_type):
>_ if class_type in preferred_class_types:
>_ _ go_to_classroom(class_type)
>_ else: loiter()
Теперь, когда игровые часы отсчитывают время и обнаруживают, что пора начать урок, NPC получают однократное уведомление и реагируют на него, не опрашивая часы 60 раз в секунду как раньше.
Почему EDA отвязывает объекты друг от друга? Для сравнения, без использования событий предыдущую проблему можно было бы решить таким образом:
>class_name Clock
>func tick():
>_ time += 1
>_ if time in class_times:
>_ _ for student in students:
>_ _ _ student.go_to_classroom(class_times[time])
Да, этот код раздает оповещения ученикам лишь по необходимости, избавляя от проблемы 60 запросов в секунду от каждого ученика. Но теперь наши "часы" совершенно внезапно знают обо всех учениках. Если необходимо добавить учителей, придётся объявлять учителей как учеников или менять код "часов". Если в будущем мы решим изменить код ученика, мы будем вынуждены изменить код "часов", т.к. он напрямую обращается к коду ученика и зависит от него. Если следовать EDA, мы делаем наш Clock независимым:
>class_name Clock
>signal class_starts(class_type)
>func tick():
>_ time += 1
>_ if time in class_times:
>_ _ class_starts.emit(class_times[time])
Как видите, код практически тот же, но теперь он не озабочен никакими учениками и учителями - они не касаются наших часов, поскольку задача часов - подсчитывать время и оповещать о начале урока.
В ситуации с карточной игрой: карта имеет своего владельца, но может и не иметь - карта не должна напрямую обращаться к своему владельцу. Т.е. если происходит событие с картой (наведение курсора, перемещение по полю и т.д.), карта должна сделать оповещение об этом, но кто на него среагирует - нам безразлично на уровне абстракции данной карты.
Владелец (менеджер) карты может вызывать у неё определённые действия, такие как "включи обводку", отвечая на событие карты "наведён курсор мыши", но владелец не обязан это делать и может игнорировать события, происходящие с картой. Карта же способна проявлять поведение без событий, как, например, проигрывание эффектов карты (блёстки и т.п.).
Это позволяет использовать карту отдельно - хоть и с ограниченным функционалом, а ещё написать новый (отдельный) менеджер для уже существующих карт. Например, менеджер поля (где лежат выложенные игроками карты) может отличаться от руки игрока, но обработка событий карты производится обоими (по необходимости, т.е. если они владеют картой).
Всё очень просто, если понимать базу.
Где ваши игры?
Мои игры на компьютерах и смартфонах игроков. Старайся лучше и тоже сделаешь игру.
>Проблема возникает из-за непонимания того, что случившееся событие - это не призыв к действию, а оповещение о том, что какое-то действие совершено. Событие никого ни к чему не принуждает, и тебя, как разработчика объекта, совершенно не волнует, кто в будущем может отреагировать на твоё событие. Но выставить событие наружу ты должен, если по плану необходимо знать о том, что что-то где-то произошло.
Так может ну их, эти события? Зачем они вообще нужны если никто не обязан на них реагировать? Или может всё таки обязан, а ты тут накатал стену неясно для кого? Я же говорю, концепция у событий простая, но в итоге она приводит к образованию сайд эффектов, от которых в итоге зависит правильная бизнес логика, а если эти события по каким либо причинам перестанут появляться, или начнут появляться не так или не туда - мы получим каскадное нарушение логики работы всех обьектов, которые по твоим словам вроде как не зависимы от событий, но при этом без их появления не будут выполнять свои функции или будут их выполнять в неожиданном порядке. Причём подчас это будет происходить не постоянно, т.н. плавающие баги. И делай что хошь с этим событийным говном. Конечно, события не декларируются как призывы к действию, но это их настоящая суть приводящая проект в пизду.
>Да, этот код раздает оповещения ученикам лишь по необходимости, избавляя от проблемы 60 запросов от каждого ученика
Другалек, а ты вообще хоть один крупный проект делал? Что за ебанутые примеры у тебя
>event-driven architecture.
Говно драйвен архитектуры. Видите такое - бегите нахуй, пусть паджиты с этим дальше ебутся.
>Чрезвычайно полезная вещь, избавляющая тебя от непрерывного запроса состояния других объектов.
Нет никаких запросов состояний, обьекты по цепочке внедренных владельцев либо сами делают что-то, либо вызывают код у своих владельцев который делает что-то, либо стучат в какой-то из синглтонов. Еще возможна локальная либо синглтон-глобальная реализация эвент лупа для утилитарных целей (балансировка, очередь с приоритетами), где события это буквально действия, упакованные делегаты, просто вызываемые не сразу.
>Во-первых, EDA отличается тем, что максимально отвязывает объекты друг от друга. Связывания не происходит, происходит лишь реакция на события.
Для отвязывания есть много других способов, при чем compile-time способов. Слышал про ООП принципы? Интерфейсы там, полиморфизм?
>Во-вторых, ты делаешь это осознанно - по плану.
Я долго придумывал шутку но так ничего и не придумал так что окей, осознанно так осознанно, хули.
И не лень тебе жирного кормить? Я его просто обоссал и пошёл игры дальше делать. И ты так делай. Игры делай.
Полностью согласен. Иначе моего баттхерта и предлагаемых ограничений по поводу проблемы событий видимо не понять. Только своими шишками.
> моего баттхерта и предлагаемых ограничений по поводу проблемы событий видимо не понять
Шину событий заводишь в корне дерева и наслаждаешься. Сигналы в годоте отписывать не нужно, хотя возможность и АПИ для этого есть (дисконнект). Как только источник подписки выгрузился, подписка отписалась сама. Этим годотовская реализация событий отличается от прочих. Безопасные подписки.
Так что просто заводим шину сигналов на верхних уровнях (можно прямо в майнлупе), и хуярим на ней контролируемые централизованные сигналы, без лапши и прочей хуйни.
Я не он, но потому что не хочется связывать свое ирл с харкачем. Но выше там кто-то поездовый хоррор свой показывал, а в прошлых тредах чуваки со своими Noesys или как-то так.
Пробовал чистить кеш, пробовал скрывать ноды, пробовал сохранять их как подсцены. Единственное что помогает - полное удаление значительной части сцен, из которых сделан уровень. Может есть способ научить годот не выгружать вкладку при переключении из нее?
Тогда надо понять что вызывает тряску, либо открывай по редактору на сцену и работай так.
Да он и не должен выгружать, дело в чём-то другом, возможно в рендеререре, похоже не хватает памяти, если у тебя 3D нажми на три точки слева сверху в окне с 3д и поставь Half Resolution
Желательно, чтобы порекомендовали уже спецы.
Движку просто куча лет и куча пользователей, может, что на русише норм появилось.
Яндекс браузер тебе переведет и озвучит. А лучше сам учи. Весь русскоязычный околоайтишный контент отстает от мейнстрима на пару лет минимум.
>Зачем они вообще нужны если никто не обязан на них реагировать? Или может всё таки обязан
1. Создай сцену.
2. Добавь Button.
3. Нажми F6.
4. Нажми Button.
Godot крашнулся с ошибкой "но ты обязан!.."?
Нет, кнопка нажалась, но Godot не крашнулся.
Значит, ты не обязан реагировать на кнопку.
>приводит к образованию сайд эффектов
Событие "нажатие кнопки пользователем" обычно приводит к какому-то "эффекту", но этот эффект - не нежелательный, а запланированный дизайнером.
Без события ты будешь 60 раз в секунду делать принудительную проверку "кнопка нажата?", либо сделаешь код кнопки владельцем совершенно не относящихся к кнопкам объектов (будет лапша).
>эти события по каким либо причинам перестанут появляться, или начнут появляться не так
События происходят обычно в "нижних" отделах приложения (листьях дерева), и поэтому не могут прекратить появляться. Ты же не меняешь код беспорядочно, верно? А если ты в команде, то ты, естественно, должен договариваться о внутренних интерфейсах и не изменять их без предупреждения.
Обычно, когда ты используешь какое-то событие (подписываешься на него), оно исходит из уже разработанного компонента и не будет меняться существенным образом (т.е. интерфейс стабилен).
>каскадное нарушение логики работы всех обьектов
Покажи пример, где там твоя логика нарушилась. Не представляю, зачем ты выстроил какое-то домино и жалуешься теперь, что оно сработало как должно. Я попробую объяснить, как это нужно было делать.
>происходить не постоянно, т.н. плавающие баги
Так ты не делай "if !random(): bug()" в коде, лалка.
Событийно ориентированная архитектура позволяет протестировать каждый из компонентов программы полностью независимо друг от друга, гарантировать корректность их работы. Уже ПОТОМ ты будешь как дизайнер связывать имеющиеся у тебя и на 100% протестированные компоненты во что-то большее (и тестировать это "большее" как цельный компонент).
Разработка снизу вверх получается - от меньших компонентов (кнопки, карты, студенты) к большим (графический интерфейс, стол с картами, школа). Отличается от разработки сверху вниз повышенной гибкостью архитектуры и работоспособностью игры буквально с самого старта, т.к. не опирается на ещё отсутствующие системы высшего уровня.
Без событий разрабатывать снизу вверх сложно, т.к. приходится залазить в кишки мелких компонентов. События позволяют мелким компонентам сообщить крупным компонентам о том, что у них произошло. Разрабатывать сверху вниз через события тоже возможно, но в геймдеве обычно всё снизу вверх - необходимо иметь рабочую игру как можно раньше.
>>1027776
>обьекты по цепочке внедренных владельцев либо сами делают что-то, либо вызывают код у своих владельцев который делает что-то, либо стучат в какой-то из синглтонов
Это так веб-макаки сегодня дрочат? Я просто не интересуюсь айти за пределами геймдева, извини.
>Слышал про ООП принципы?
События - это расширение ООП. Без принципов ООП далеко не уедешь, а без событий некомфортно ехать.
>Яндекс браузер тебе переведет и озвучит.
гэбня нинужна, хочу цру или китайцев на худой конец
>А лучше сам учи.
нафиг, я буду учить тока, как игоры делоть и другие программы на годоте
>Весь русскоязычный околоайтишный контент отстает от мейнстрима на пару лет минимум.
не надо так шутить, плз
В лучшем случае ты просто не хочешь ничего делать и лепишь отмазки. В худшем залетел потраливалить. Отлетаешь в любом случае.
Увы, не помогает. Долго думает на переключении даже если скрыть все элементы уровня. Более того - долго думает даже если я не в 3д редакторе, а в скрипт-редакторе, и переключаюсь на вкладку своего огромного уровня (оставаясь при этом в редакторе скриптов).
>Godot крашнулся с ошибкой "но ты обязан!.."? Нет, кнопка нажалась, но Godot не крашнулся.
Это и есть минус о котором тебе твердили выше. Это тоже вид бага, неправильная подписка, только более трудно отлавливаемый чем ошибка в прямом обращении. (В реальной разработке как раз предпочитают чтобы был краш с логами чтобы сразу найти место ошибки - поскольку гдскрипт не компилируемый).
>Без события ты будешь 60 раз в секунду делать принудительную проверку "кнопка нажата?"
Буквально большинство экшн, реалтаймовых игр на годоте так и работают. Input.is_pressed(), Input.is_just_pressed(). Вот что полезно так это второе, паттерн Latch (задвижка) известный еще с 80-х. Когда нажатие выставляет флаг, и он остается взведенным пока не будет считан. А события притащены всякими веб макаками, ну есть определенные игры типа кликеров где с ними удобно, но подозреваю что это меньшинство.
>либо сделаешь код кнопки владельцем совершенно не относящихся к кнопкам объектов (будет лапша).
Не делай в не относящихся, делай в нужных менеджерах.
>Так что просто заводим шину сигналов на верхних уровнях
Это буквально определение лапши. Потому что в эту шину все срут и неизвестно кто читает (еще и не то что им предназначалось, то есть они еще и лишнюю производительность тратят на отфильтровывание того что не для них).
>Проблема - открытие этого уровня в редакторе, или переключение вкладок с уровня на что угодно и обратно, занимает секунд 5
Это нормально и ожидаемо.
Я не знаю точно, так как не изучал соответствующие исходники, но насколько я понимаю, всё, что видно в редакторе - это ноды, да, точно такие же, как у тебя в интерфейсе игры. При переключении вкладок старая сцена удаляется из дерева, а новая добавляется. А добавление нод в дерево в Godot - это одна из самых затратных операций - не рекомендуется добавлять за один раз больше пары десятков нод, ибо дерево сцен работает в одном потоке, там много чего происходит.
>при активной работе над ассетами приходится прыгать туда-сюда по вкладкам
Разделяй свой уровень на уникальные подсцены:
>город
>_ квартал
>_ _ дом
>_ _ _ этаж
>_ _ _ _ квартира
>_ _ _ _ _ комната
Даже если ты никогда не будешь использовать сцену "квартира" больше одного раза, имеет смысл хранить отдельно от "этажа" и "дома", чтоб тебе было удобнее редактировать и не нужно было лишний раз вкладки переключать. А для гигантских сцен типа "квартал" и "город" нужен свой собственный загрузчик по типу чанкового, с LODами и т.п. Базовый загрузчик Godot подходит только для небольших и средних сцен.
> У меня уровень, состоящий из пары тысяч сцен
Его не спроектировать на тайлах что ли?
сдох?
>вид бага, неправильная подписка
Так подписывайся правильно и тестируй чаще. Ты же можешь запустить компонент отдельно от остальных.
>предпочитают чтобы был краш с логами
То-то в GTA десятилетиями баги не фиксят...
>Input.is_pressed(), Input.is_just_pressed()
Для 99% задач хватает _unhandled_input. Я бы сказал, постоянно запрашивать Input - это антипаттерн, с ним множество проблем в проекте сложнее "hello world". Обычный _input тоже редко нужен, юзай unhandled.
>Когда нажатие выставляет флаг, и он остается взведенным пока не будет считан.
Это уже внутренняя кухня конкретного объекта. Мы обсуждаем внешнее взаимодействие объектов.
>события притащены всякими веб макаками
Это древняя концепция, на ней же построены RAD IDE наподобие Delphi и прочих. Веб в то время был в виде статичных текстов со ссылками без украшений. Вебу события не нужны в большинстве случаев, т.к. там stateless серверы, они отдают страничку и всё.
>делай в нужных менеджерах
У тебя в любом случае менеджер будет, но благодаря событиям тебе легче с ним работать - т.к. он избегает необходимости копаться в том, что он там менеджит. События подключается к менеджеру, чтобы он знал о происходящих событиях у его подопечных объектов.
Ты так и не рассказал о "каскадном нарушении"...
>gdscript-cheatsheet
Я посмотрел в архиве:
https://web.archive.org/web/20241229013813/https://godot.community/topic/78/gdscript-cheatsheet
Там нет ничего, чего не найти в документации:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html
Читай документацию в первую очередь.
>спроектировать на тайлах
У него же 3D игра, лол. Или ты про чанки?
Пара тысяч сцен - это нормально, если ты много чего копипастишь, типа коробок всяких. Предполагаю, он навалил декораций и теперь они долго загружаются. Поэтому переключается между мелкими сценами и громадной сценой. Нужно резать на чанки/комнаты.
Такое бывает, когда бросаешься делать Игру Мечты™ толком не разобравшись в своих инструментах и как обычно делаются проекты подобных масштабов.
Но, конечно, Godot тоже виноват, что вообще никак не предупреждает о таком ограничении/подвохе...
Ну я ебанул 3500 пустых MeshInstance3D и вижу то-же, что и у тебя, дело в редакторском SceneTree. При переключении память не осбождается почти но перестраивается дерево может он там сверяет трансформации ещё проходя по дереву. Я попрбовал прелоадом в реди тул скрипта добавлять эти 2 сцены но не помогло, не вижу какого-то выхода простого
>эти 2 сцены
случайно стёр, что разбил на 2 сцены по 1500 нод
Спасибо, анончик. Следующие уровни разобью на куски поменьше, чтобы лепить их легче было, а этот так доделаю.
>>1027886
Слушай а тебе ошибки не срутся в аутпут типа таких
Я мешинстанс заменил на Node3D, на пикче1 под каждой нодой 1500 нод и всё летает, ну у меня meshInstance получили ссылку в поле Skeleton и путь был не верный, сейчас вернулся и сделал кучу meshinstance пустых ~4000 , ну да секунд 5 переключает и не важно видимые или нет, какая-то внутрянка тормозит, в принципе на это можно бы создать issue
>тестируй чаще
>Инди геймдев
>Уебищный гдс без фреймворков для тестирования
>Ну ладно с#, но проблема индигеймдева в 1 лицо не снята
Смешно, пиши ещё
>Это уже внутренняя кухня конкретного объекта. Мы обсуждаем внешнее взаимодействие объектов.
Задвижка взводится как раз в обьекте который опрашивается, впрочем паттерн действительно сомнительный
>У тебя в любом случае менеджер будет, но благодаря событиям тебе легче с ним работать - т.к. он избегает необходимости копаться в том, что он там менеджит. >События подключается к менеджеру, чтобы он знал о происходящих событиях у его подопечных объектов.
Обьясни в чем в таком случае разница между вызовом метода и отправкой события и нахуя в таком варианте события нужны вообще (ну кроме как для лишней аллокации, тема завсегда нужная).
Получается - мы потеряли компайл-тайм подтверждение что ожидаемая логика выполнится, у нас добавилась проверка типа события и лишняя аллокация - просто чтобы разорвать возможность напрямую вызвать метод? А профиты где? Если потребуется рефакторить событие - рефакторить его придется у всех либо создавать на его основе новое событие с изменениями, но у нас языком предусмотрена на такой случай перегрузка метода и вот снова событие не нужно. А если передавать в методе интерфейс отправителя - то и вовсе можно напрямую ковыряться в отправителе и получать часть его данных, без упаковки в событие, на случай если потребуется на него опереться, что редкость.
>Ты так и не рассказал о "каскадном нарушении"...
Рассказал, ты просто невнимательно читал. Вот уже мы сузили применимость событий с шины (event driven) до собственно простого вызова метода с событием в которое ты засунул данные, еще немного и ты познаешь дзен их ненужности...
В 4.4 было такое, на базе вот этого issue: https://github.com/godotengine/godot/issues/83460
Ты на какой версии проверял? Просто я вообще на тройке.
Она ранее наверное ещё хуже работало, но в данном случае проблема с наследниками GeometryInstance3D и видимо их перерегистрацией на RenderingServer
Сохрани свои шумы как файлы. Если рандомизация нужна наделай х5 от нужного и выбирай рандомный набор. Материалы с уже натянутыми текстурами тоже сохранить можно.
Это вариант, но я пока склоняюсь к тому, что мне нужно прям огромное кол-во этих шумов. Но это, скорее спортивный интерес и если у меня ничего не получится, буду вынужден посохранять.
Ты б сначала замерил действитеольно ли генерация занимает большую часть времени или это создание материалов.
Ну и как оптимизацию делать генерацию можно в отдельном потоке.
Больше не актуален?
Зачем тогда его тащить из шапки в шапку, там вообще сдохший сайт висит.
Тайлы для 3д называются GridMap, ими тоже можно расставлять коробки с коллайдерами. А если без коллайдеров и логики, то можно замутить MutliMesh Instance, есть аддоны для батчинга-склеивания/расклеивания на индивидуальные. Или можно сделать чтобы в редакторе виден мультимеш, а при загрузке на места инстансов грузились сцены с логикой. Этакий object pooling
Еще можно попробовать сохранить сцену в бинарном виде (.scn вместо .tscn), возможны риски, так что бэкапиться чаще.
Ограничься двумя картами шумов и например складывай их значения по какой то формуле (A[x,y] + B[x+id,y])
Вообще говоря, если разобраться в шуме, то можно создать одну карту побольше например 1024x1024 и выбирать разным объектам из нее разные квадраты, например с коориднат 96,48.
Или например есть 3d noise texture. Может быть она будет работать быстрее (а глубину использовать как индекс 2д среза шума).
Кроме того, может быть тебе вообще не надо создавать текстуры шума, а просто генерить его кодом в шейдере. Возможно в твоем случае это будет даже производительнее..
>постоянно запрашивать Input - это антипаттерн, с ним множество проблем в проекте сложнее "hello world".
Открой любой 3д проект с контроллером персонажа, вот там в 99% будет Input.get_vector("left", "right", "up", "down")
https://www.youtube.com/watch?v=z23MQ2xad30&list=PLpp4UXjsd_VeN7FrIbk7suElcL3bm6eLB
Нормальный если тебе обязтельно на русском, но учти что будут моменты что ты сделал всё один в один, а у тебя не работает, обычно надо дальше посмотреть или в комменты глянуть там бывают косяки описаны.
>7:09 создание кнопок
Мультиплеерных?
Кстати, теперь я понял откуда знакомый мне скрины "своей" игры кидал. Вот из этого курса.
Команда разработки движка отказывается сделать в гдскрипте list comprehension, мотивируя это тем, что такой синтаксис "неудобочитаем". В результате я должен вместо элегантного
var item_descriptions = [item.description for item in items]
городить неуклюжий for на 3 строчки
Доколе?
>мотивируя это тем, что такой синтаксис "неудобочитаем"
Они мотивируют это тем, что:
- это нужно лишь <0.1% юзеров, т.е. НИНУЖНО;
- они не хотят поддерживать лишний сахар;
- есть filter(), map(), reduce(), any(), all().
>городить неуклюжий for на 3 строчки
https://docs.godotengine.org/en/stable/classes/class_array.html#class-array-method-map
Если я правильно понял, ты хочешь что-то такое:
>var item_descriptions = items.map(func(item): return item.description)
На твоём месте я бы задумался, так ли уж нужно копипастить эти данные...
>400 карт шумов 512х512
Если тебе обязательно нужно 400 уникальных шумов, и на каждый запуск игры они должны отличаться от предыдущих или меняться по каким-то правилам в реальном времени в процессе игры, то тут ничего не поделаешь - придётся ждать. Процедурная генерация редко используется в том числе из-за длительности запуска игры, что зачастую не оправдывается достоинствами процедурной генерации.
Если тебе достаточно 400 заранее созданных уникальных текстур, которые никак не меняются ни в процессе игры, ни после запуска новой игры, тогда логичным решением будет сохранить сгенерированный шум в PNG в папке проекта и затем заменить все NoiseTexture2D на ImageTexture. Можно автоматизировать процесс tool-скриптом. Так вместо генерации новой текстуры в рантайме из шума она будет считываться с диска.
Если тебе на самом деле хватило бы 1 текстуры шума, вставленной в 400 отдельных материалов, тогда сохрани один NoiseTexture2D в файл .tres и вставь этот файл во все материалы, которым нужен шум. Тогда шум будет сгенерирован один раз, на первом материале, а дальше будет использоваться ссылка на уже готовую текстуру (до тех пор, пока существует хотя бы один материал, использующий эту текстуру; если удалить все материалы, а потом снова добавить один, эта текстура перегенерируется с нуля).
Покажи хоть скриншот того, что ты там делаешь... Интересно же.
>это нужно лишь <0.1% юзеров
Мне больше интересно, кому нахуй нужна поддержка инвалидов, особенно слепых, тем более что с ней они все равно не поиграют ни во что, кроме новелл которые для них будут вообще текстовыми квестами. Это реально меньше 0.001% юзеров, а они корячат в двигло access kit, как будто это кому-то надо кроме его корячителя. Я думаю просто некому внедрять это вот и всё.
> в эту шину все срут
Не срут, а читают и отправляют сообщения. Не все, а те кому нужно.
> и неизвестно кто читает
Известно. Кто подписался, тот прочёл. Кто отписался, тот перестал читать. Кто желает испустить сигнал, тот вызвал эмит() на интересующем его сигнале.
> лишнюю производительность тратят на отфильтровывание того что не для них
Не тратят. Если ты подписан - ты реагируешь на испущенный сигнал, если не подписан, то ничего не фильтруешь. Если сигнал с данными (эмит(аргумент), то эти данные для тебя и для всех, кто подписался на сигнал. Если тебе из сигнала с данными приходится данные фильтровать - значит накосячил с архитектурой проекта.
У паттерна "event bus" есть свои минусы, но ты своим набросом не попал ни в один. Старайся лучше. Делай игры.
Что будет если в одном из событий по неизвестной причине придут сериализованные данные с null? Как отследить отправителя и понять что привело к такому исходу? Или предлагаешь внедрять стектрейс в каждое чтобы не прогадать? Условно какой-то паджит сделал 0.000001f == 0.0000000004f и поле не присвоилось, а у события больше чем 1 отправитель. А что если прием сигнала вызывает в итоге отправку еще 1 сигнала и только там ты словишь исключение на null? Не говоря о том что каждое событие это аллокация и проверка типа этого события в самой шине. Гонка актуальности событий, из-за чего у людей происходит поражение/смерть после победы, потому что не учли, анон выше тоже про это писал. По мне так пусть лучше делают максимально без них, и оставят эту игрушку дьявола тем у кого реально есть ресурсы на юнит-тестирование и нанимание на работу людей понимающих эти ньюансы.
> Гонка актуальности событий, из-за чего у людей происходит поражение/смерть после победы, потому что не учли, анон выше тоже про это писал.
Анон выше смешал в кучу всё подряд. Если у тебя правильно написанная стейт-машина, то после того как она перешла в состояние победы, она уже не сможет перейти в состояние смерти, какие бы сигналы ей не прилетали бы по её подпискам.
> Что будет если в одном из событий по неизвестной причине придут сериализованные данные с null?
В зависимости от требований и задач, подписанный на это событие агент проигнорирует это событие, либо сгенерирует данные по-умолчанию, либо вызовет событие уведомления об ошибке в пользовательском интерфейсе. Если проектируется многопоточная и/или распледеленная система - такие случаи учитываются на стадии проектирования.
> Условно какой-то паджит сделал
Если твои паджиты работают не по твоему диздоку, не покрывают свой код тестами, а ты не проверяя платишь им деньги, то виноват не движок, ехехе.
>Анон выше смешал в кучу всё подряд. Если у тебя правильно написанная стейт-машина
Оп, а вот и задвижка подьехала. То есть у нас уже даже 2 лишних сущности, которые должны поддерживать работоспособность этой лапшичной. Вообще конечно можно без нее, а просто правильно управлять самой шиной, чтобы в любую секунду просто чистить ее и таким образом избавляться от стейтмашины, но нужно чтобы туда попадали только события которые готовы к такому подходу.
>В зависимости от требований и задач, подписанный на это событие агент проигнорирует это событие, либо сгенерирует данные по-умолчанию, либо вызовет событие уведомления об ошибке в пользовательском интерфейсе.
Мне похуй что он там сгенерирует, отлаживать это говно как? Как воссоздать ситуацию приведшую к этому говну? Написать ещё больше тестов? Или сидеть думать полдня гуляя по цепочкам связей? Я инди, мне не до такого, команды паджитов у меня нет, а была бы - я бы им не позволил привести ситуацию к такому раскладу.
>Если твои паджиты работают не по твоему диздоку, не покрывают свой код тестами
Я с одного выше проигрывал с его тестами вот тут
>>1027892
повторяться неохота.
У того же русяз челика, новый курс по Годоту.
Игра на Годоте 4.3 с нуля.
Тем что его баги наконец зазернились в катарсисе и движок перестал ломаться на каждом релизе. Ну а еще там можно c# в вебе пилить
Корпоративный лангуаге.
Собственность Микросот вместе со всем Нет.
Ты чет попутал. В тройке опенсорсный моно, а дотнет так и вовсе под mit. Впрочем - кто его будет развивать если не ms - вопрос риторический, да, просто останется опенсорсный монолитный памятник.
Если не выискивать какие то дикие курьезные исключения, то ЯП (как лингвистическая сущность) не может кем то владеться или быть подкопирайтной. То есть никто не может тебе запретить сделать свой компилятор c#, со своим апи и либами. Вообще консенсунс такой что и апи и либы можно тоже юзать, по результатам суда гугл андроид vs oracle java В худшем случае запретят.использовать название c#, ну назоаегь СиХэш.
Патенты будут только на какие нибудь оптимизации в компиляторе, не на язык.
А как тебе патенты мешают то? Или тебе хочется написать свой mono.runtime/core clr но не можешь из-за патентов? Ну тогда видимо ты тредом ошибся, потому что любой язык из топ-20 имеет патенты, самое время начать писать собственный язык.
Смотри на суды Оракла с Гуглом из-за Андроида.
Естественно, это ЦРУ продавило решение в пользу Гугла, потому что это чисто их проект.
Кто будет заступаться за других?
Никто.
И тем более, если ваша компания - не из США.
Как вывод:
Не использовать ничего из .Нет вообще.
А сразу брать чистое СПО изначально.
> никто не может тебе запретить сделать свой компилятор
Как же хочется отдельный от годота системный компилятор GDScript, если бы вы знали, но вы не знаете. Хочется консольные утилиты на нём писать. Хочется писать на нём оконные приложения. Хочется вот так:
> class_name Program
> func main(args: Array[String]):
> > var app := Application.new()
> > app.run()
Есть GNU аналог, Vala называется, он еще и задуман вроде чтобы в линуксе транспилироваться в быстрый C и без GC.
https://wiki.gnome.org/Projects/Vala/ValaForCSharpProgrammers
https://wiki.gnome.org/Projects/Vala/ValaForJavaProgrammers
Так он базу говорит. C/C++ ок, там общественные комитеты создают стандарт. GDScript ок, он создан специально опенсорсным. А С# это третья нога.
А что будет когда придёт тролль и заявит патент на твое безпатентное спо? И скажет что любой продукт который содержит в составе это спо теперь должен ему ундециллион денег?
Мало того, майкрософт обещал не судиться по патентам с Моно и подобным, но что если наступит вендекапец, майкрософт разориться? И вот тут то патенты и выкупит какой то тролль, как уже бывало в истории.
Так он выкупит патенты только на реализацию по ecma шарп спицификации. Да, моно попадет под раздачу, но моно и так практически труп, по итогу просто нужно будет перенести с дотнета на что-то ещё.
Я тоже делаю. Мне даёт. Но хочется системно. А щас делается прикладнО.
>особенно слепых
Большинство не совсем слепые, а слабовидящие. С возрастом зрение обычно ухудшается. По опыту могу сказать, что красочные иллюстрации смотреть и с ослабленным зрением норм, а вот текст читать - это проблема. Лично я TTS не пользуюсь, но кому-то он наверняка полезен даже в играх. Minecraft вот даже реализовал TTS для чата... и субтитры для звуков. Во множестве игр текст настолько мелкий, что просто размазывается сглаживанием в нечитаемую кашу - поэтому ИИ скринридер не распознает символы.
Вообще, логика у тебя уровня:
>Зачем делать биндинг клавиш? Мне и так норм.
А потом тебе будут негативные отзывы от AZERTY.
>Хочется консольные утилиты на нём писать.
https://docs.godotengine.org/en/stable/tutorials/editor/command_line_tutorial.html#running-a-script
https://docs.godotengine.org/en/stable/classes/class_os.html#class-os-method-get-cmdline-args
https://docs.godotengine.org/en/stable/classes/class_mainloop.html
>системный компилятор GDScript
Добавь папку с godot.exe в PATH, тогда сможешь из командной строки запускать скрипты как на питоне. Компилировать в принципе можно транспилером, но официальной поддержки пока нет (планируют).
>писать на нём оконные приложения
Что-нибудь наподобие Godot Editor?
https://docs.godotengine.org/en/stable/classes/class_projectsettings.html#class-projectsettings-property-application-run-low-processor-mode
Крч я заебался и решил выпатчить ее к хуям. Скачал исходники годота, 3 минуты найти грепом что закомментить, 2 минуты на сборку движка, и все.
И хочу сказать что я не ожидал что годот так легко патчится-билдится. Так и на гитхаб патч отправить не долго.
Этот сдох.
Нормально, только я бы наверное не возился с пересборкой, а нашел ее плагинскриптом в окне, ведь окно годота это игра на годоте и можно искать прямо соответствующую ноду.
>2 минуты на сборку движка
Звучит как правда, у меня 20 минут собирается, у тебя видимо суперкомпьютер
Да, я пытался сначала плагин написать, но не нашел ничего что можно было бы дернуть, чтобы убрать эту бесячую залупу. Вот бекпорт из 4.х в 3.6, может ты осилишь: https://github.com/godotengine/godot/pull/70185/files
Чё ты там неуниформно скейлишь, лол?
1. Текстуры раскорячит, даже трипланарные.
2. Физика вообще не дружит со скейлом.
3. Ноды-пустышки? Но зачем? ЗАЧЕМ?
Я стараюсь скейл не трогать вообще.
Алсо, не забывай об ошибках округления...
>print(scale)
>Vector3(1.0, 1.0, 1.000000000000000000069)
Потом ломаешь голову, почему не работает...
ОСОБЕННО если скейлишь ноды в цепочке.
А я не отключаю связь масштабов. В физическом движке non uniform вроде не будет работать, а визуально я тоже нахапался раньше проблем, и пришел к подходу "честных исходных данных", если я хочу стену 1х2,5, то я меняю вершины, а не растягиваю куб 1х1, аналогично с модельками, фиксил как то кривую модельку приплюснув ее, словил каких то проблем то ли с анимацией то ли еще с чем, переделал в итоге в блендере на 1 к 1.
>>1028084
Да-да, расскажите как мне это нинужно, учитывая что визуальный scale mode даже в четверке до сих пор не юниформ и никого он не смущает. Тут у нас так, а тут иначе, а почему а вот потому что слышь тебе нинужно. Дело движка предупредить, а форсить меня в тот или иной воркфлоу не его дело.
Крч закоментил-перекомпилил и хуй с ним, без плагина обойдусь.
>профиты где?
>>1027987
>отлаживать как?
Подумал-подумал и осознал, в чём твоя проблема. Ты привык писать код сверху вниз, засовывая максимум функций и логики на верхние уровни абстракции, т.е. условный скрипт game.gd, в котором у тебя 99% всего игрового кода работает. Если так - всё верно, тебе нет необходимости объявлять сигналы, ты просто всем руководишь сверху. Но это не всем подходит.
Альтернатива твоему подходу, которую продвигает философия Godot - это разработка снизу вверх, когда основные функции и логика находятся где-то внизу, в "листьях" дерева сцены, распределены между очень большим количеством скриптов и вложенных сцен. Поведение приложения не закладывается заранее, а проявляется эмерджентно, т.е. из взаимодействия множества никак не связанных компонентов.
Наглядный пример:
1. Сверху вниз: глобальный ИИ-дирижёр указывает бездумным пешкам, куда им идти, что делать; в ГТА глобальный ИИ-полицейский раздаёт всем юнитам местоположение игрока и требует его убить.
2. Снизу вверх: независимые ИИ-граждане решают локальные для них задачи автономно; в ГТА один полицейский с таким ИИ может проигнорировать пробегающего игрока, если он потерял рацию и не наблюдал лично совершение преступления.
В первом случае ты УЖЕ ЗНАЕШЬ, что делает каждая конкретная пешка, ведь у них у всех отсутствует своё собственное, индивидуальное поведение. Т.е. тебе совершенно не нужно слушать их сигналы.
Во втором случае по умолчанию ты ничего не знаешь, потому что каждый персонаж действует независимо. Однако, если ты хочешь организовать их, тебе всё же необходимо как-то передавать информацию одного персонажа остальным. Например, если ты хочешь оповестить всех полицейских, если один из них вдруг заметил игрока на месте преступления. Логичным и удобным будет добавить персонажу сигнал "замечен преступник", который вызывает сбор всех остальных полицейских к месту излучения сигнала.
Т.е. ты не понимаешь смысл сигналов/событий, т.к. используешь противоположный подход к разработке приложений. Если тебя удовлетворяет делать так, то никаких проблем нет. Но разработка сверху вниз как правило очень жёсткая и практически не допускает экспериментов, не обладает эмерджентностью.
Конечно, в реальной работе имеет смысл идти не полностью снизу вверх, а "изнутри наружу", т.е. из приблизительной середины вверх и вниз. Т.е. у тебя существует какая-то глобальная задумка, но ты ей оставляешь пространство для гибких манёвров. Т.е. персонаж сам по себе делается сверху вниз, а вот организация персонажей получается снизу вверх.
Короче говоря, если тебе не нужно - не пользуйся.
>Ты привык
Первая ошибка. Я могу писать как угодно, с любыми паттернами, строить какие угодно карточные и не очень домики из абстракций. Просто за последние 5 лет работы в энтерпрайзе + в индюшатнях на юнити до этого я понял градации сложности кодовой базы которую один человек может потянуть, а какую не может потянуть, либо может но с большими трудностями, прорываясь через тонны багов и слабо учтенных моментов, навроде описанных мной выше. И на самом деле события далеко не едиснтвенный враг соло программиста, в который можно начать играть и проиграть. Я может быть был несколько категоричен в отношении их ненужности, но в большинстве сценариев без них действительно можно обойтись, если построена достаточно гибкая архитектурная абстракция.
2 ошибка:
>Сверху вниз: глобальный ИИ-дирижёр указывает бездумным пешкам, куда им идти, что делать; в ГТА глобальный ИИ-полицейский раздаёт всем юнитам местоположение игрока и требует его убить.
Я бы так не стал делать ни при каких обстоятельствах. Все ведомства должны заниматься своими делами - инстанс пешки должен инкапсулировать ее поведение согласно конфигу, фабрика пешки возвратит ее (синглтону/более высокому управляющему звену) конвееру NPC глобального мира вместе с ее физикой, анимациями и прочим что инкапсулирует пешка, формируя это из ее конфигурации. Пешка сама хранит собственные обьекты, сама ими управляет, получая пинок из конвеера NPC. Я могу пробрасывать зависимости вниз от конвеера до автомата пешки либо руками, либо используя нодовый контейнер, из которого при острой нужде могу извлечь на верхнем уровне определенные нижние зависимости, что в общем-то не слишком хорошая, но при необходимости осуществимая практика. И в отличии от шины событий - отсутствие ожидаемого содержимого контейнера гораздо проще отладить, ведь его элементы в нем прописываются пожизненно и из 1 места для обьектовой ветки.
>В первом случае ты УЖЕ ЗНАЕШЬ
Нет, не знаю. Год обжекты зло, иногда необходимое чтобы добиться важных оптимизационных результатов, но всё же зло.
При чем конкретно я в данный момент вообще завязал с этими сомнительными практиками и пересел на собственный ecs-like фреймворк с контрактами и коробочным мультипотоком.
То что ты предлагаешь это анонимные функции. Понимаю что ими тоже можно, но согласись что такие конструкции считываются глазом куда хуже, да и beginner-friendly такую математику не назовёшь
> согласись что такие конструкции считываются глазом куда хуже, да и beginner-friendly такую математику не назовёшь
Не соглашусь. Вполне читаемо. Особенно новичку, потому что мне, старичку паскаля, наоборот было труднее принять для себя тот факт, что определения функции можно пихать в аргументы других функций. Именно новичку глубоко поебать, где объявлена функция, у него нет детской травмы насчёт того что функция когда-то 40 лет была фундаментальным закостеневшим элементом синтаксиса и дизайна.
>Именно новичку глубоко поебать, где объявлена функция, у него нет детской травмы
Ты ошибаешься. Всякие лямбды сложно считываются новичками. Они вообще функции не любят. А вот операторы воспринимают спокойно.
им больше по душе print 'hello world', чем print('hello world')
и предпочитают a,b,c = [a,b,c,d,e][0:3] вместо того что ты там дал в качестве примера
Не согласен. Новички не видят разницы между оператором и замыканием. Замыкание для новичка - это такая разновидность оператора.
> вместо того что ты там дал в качестве примера
Что я там дал? С подливой?
>То что ты предлагаешь это
Функциональный подход, т.е. основа питона.
>>1028183
>мне, старичку паскаля, наоборот было труднее принять для себя тот факт, что определения функции можно пихать в аргументы других функций
Не, это как раз легко принять. Что трудно принять - отсутствие ВЛОЖЕННЫХ функций внутри других. Для примера, почему GDScript не позволяет сделать так?
>func outer(x):
>_ func inner1(x):
>_ _ func inner2(x):
>_ _ _ func inner3(x):
>_ _ _ _ return x + 1
>_ _ _ return inner3(x) + 1
>_ _ return inner2(x) + 1
>_ return inner1(x) + 1
>print(outer(1)) # ответ: 5
Это крайне полезно на Pascal, почему здесь нет? Т.е. приходится зря захламлять общее поле видимости локально изолированными функциями. Обидно.
>>1028189
>Они вообще функции не любят
Пускай привыкают, дробление на функции - база.
>предпочитают a,b,c = [a,b,c,d,e][0:3]
Херня какая-то нечитаемая, лучше уж так:
>a = arr[0]; b = arr[1]; c = arr[3]
ОДНАКО, если ты хочешь разделить массив на набор именованных переменных, ты уже где-то накосячил и необходимо рефакторингом заниматься.
Помни: у переменных в массивах нет личных имён; в массивах однородные данные с общим именем. Если посмотреть на Array в GDScript, может показаться, что массивы могут содержать что угодно (Variant), но тебе следует избегать сваливать в кучу разные данные.
Ассоциативные массивы (Dictionary) - другое дело.
> Т.е. приходится зря захламлять общее поле видимости локально изолированными функциями. Обидно.
Интересно, интерпретатор GDScript оптимизирует это? Потому что выглядит как парсинг + присваивание на каждый вызов, что явно плохо. Компилируемый ЯП, очевидно, скомпилирует всё как надо, а с GDScript на данном этапе непонятно что получится.
Можно протестировать, вызвав 10.000 раз в цикле с разными вариантами. Скорее всего будет медленнее обычного объявления функций в скрипте.
>>1028232
Циферки поставил чисто для лучшей читаемости. Технически они, конечно, не нужны.
>достаточно гибкая архитектурная абстракция
Но ведь эта гибкость достигается на событиях. Без событийности у тебя будет постоянное связывание в неожиданных местах, которые трудно отследить и приходится доверять компилятору (который тупит).
Архитектура на событиях подобна конструктору Лего: кирпичики независимы и тривиально соединяются в желаемую конструкцию, и так же легко разделяются.
>градации сложности кодовой базы которую один человек может потянуть, а какую не может потянуть, либо может но с большими трудностями
Эта сложность на 99% зависит от хотелок. Если ты пытаешься разработать ММО экшн РПГ с физикой и симуляцией экосистем в космосе, тогда ты с любой архитектурой зафейлишься. А обычный платформер разработать проще на архитектуре с событиями.
>Я бы так не стал делать...
И сразу описываешь архитектуру сверху вниз:
>...фабрика пешки возвратит ее (синглтону/более высокому управляющему звену) конвееру NPC глобального мира...
Если у тебя не "сверху вниз", у тебя нет управляющего (изначально по крайней мере; позже его доделаешь). Попробуй добавить свою пешку на пустую сцену и запустить - что заработает, а что не заработает?
Т.е. ты делаешь сверху вниз и не осознаёшь этого. По крайней мере описываешь всю систему сверху вниз.
>в отличии от шины событий
"Шину событий" предложил другой анон. Лично я (мои сообщения тут самые длинные, лол) против создания глобальной "шины событий", ибо это тупо синглтон. А синглтоны чаще вредят, чем приносят пользу.
Я рекомендую использовать события локально - т.е. излучатели сигналов сидят рядом с получателями. В сложных случаях делаешь релейную систему, чтобы избежать лишнего связывания независимых систем. Ошибки легко локализуются, т.к. если у тебя что-то сломалось, ты уже знаешь, где оно сломалось. Код не размазан по всему проекту, а чётко собран.
Да, я согласен, что кода (строчек и файлов) в целом получается больше. Но это не проблема. Проблема - отсутствие гибкости на стадии хаотичных изменений, которая самая важная в разработке игры. Кто-то ECS рекомендует, а я рекомендую ООП с событиями, оба варианта по-разному решают одну проблему в коде (избыточное связывание независимых систем).
>>В первом случае ты УЖЕ ЗНАЕШЬ
>Нет, не знаю. Год обжекты зло
Речь не об объектах в коде, а о геймдизайне. Ты УЖЕ ЗНАЕШЬ (как человек), что твои NPC обязаны будут разыгрывать в игровом мире, и соответственно тупо приказываешь им сверху вниз. Это логично для игр наподобие ААА кинца-мыльца, но если твой план не идеален, переигрывать всё будет очень сложно, т.к. изначально не планировалось делать как-то иначе.
Если делать снизу вверх, ты делаешь NPC, которые теоретически могут играть любую роль в любом, не запланированном изначально сценарии. Для этого требуется, чтоб они существовали независимо, как самостоятельные программы, которым можно дать приказы, но которые действуют сами по себе. Без использования событий ты не знаешь, что там у них происходит (либо залез внутрь и дёргаешь кишки).
Godot просто даёт удобный инструмент, чтобы ты не изобретал велосипед ради решения этой задачи...
>пересел на собственный ecs-like фреймворк
...а, так ты у нас изобретатель велосипедов, лол.
Мне ECS не нравится из-за слабого зацепления. Т.е. связность снижается, но сцеплять код становится значительно сложнее, чем в классическом ООП. Это называется, вроде, деструктивным развязыванием. Отсутствуют конкретные объекты, всё лежит в виде развалившихся по разным "системам" потрохов.
Понимаю, если ты хочешь делать игру независимо от игрового движка. Но на мой взгляд, это избыточная абстракция для 99.9% разработчиков игр. Во-первых, большинство игр никогда не увидят свет. Во-вторых, переписать на другой инструмент проще, чем что-то изобретать с нуля. В-третьих, альтернатив Godot не существует пока и вряд ли что-то скоро появится (проприетарные движки вообще не рассматриваю).
> "Шину событий" предложил другой анон. Лично я (мои сообщения тут самые длинные, лол) против создания глобальной "шины событий", ибо это тупо синглтон. А синглтоны чаще вредят, чем приносят пользу.
Некоторые паттерны - это тупо переименованный синглтон. Потому что синглтоношизики вконец охуели. Например, паттерн обсервер - это тупо синглтон. Паттерн менеджер - это тупо синглтон. Процессор - синглтон. Свердловск - синглтон.
Процессор - уже не синглтон, с тех пор как появился Intel Adler Lake. С парой мощных ядер и четверкой экономичных урезанных. Как можно догадаться, сингтоношизики (которые считали процессор одним синглтоном) грустно пошли переписывать софт, ведь они полагали что ядро всегда одинаковое, неважно на какое попадет поток.