Шапка: 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. С парой мощных ядер и четверкой экономичных урезанных. Как можно догадаться, сингтоношизики (которые считали процессор одним синглтоном) грустно пошли переписывать софт, ведь они полагали что ядро всегда одинаковое, неважно на какое попадет поток.
Ты это синглтон. Как нам переписать тебя под кнопочно-мультиплеерную архитектуру?
Че за шлюха?
Какая драма?
Мы же игры делаем, а не бвитеры читаем
Какой то срачер пытался накидывать, но его все просто скрывали. Он так и ушел грустным.
Годот хорошо подходит для такого? Ну по сравнению например с УЕ?
Уе и мобилки несовместимы. Даже если он там заведется - размер игры будет вызывать оторопь и у тебя и у игроков. Годот годится только если у тебя вместо комьютера процессоросодержащий продукт 2 ядра 2 гига 4-8 гига. Если есть 16 оперативы, ссд и хотябы зеон с алика - бери юнити и твори. На годоте тоже можно но оно того не стоит.
Не, я под пека/мак.
>На годоте тоже можно но оно того не стоит.
В смысле?
Годотя обиделси.
>>1028497
>В смысле?
В прямом. Инструменты хуже чем в последних версиях юнити, и на порядки. Если в какой-то момент хочешь сбежать с пк - окажешься в аду дерьмовой поддержки на мобилках 4 версии. Захочешь освоить нормальный язык а не гдс - лови на посошок очень тяжелое срущее в память апи в виде гднатив, отсутствие веба и принуждение к частичной кодовой базе на гдс просто чтобы эта хуйня перестала быть такой лагающей. Выберешь 3 годот чтобы с с# и стабильно работающей мультиплатформой - готовься делать половину работы за движок, потому что физика лагающее дерьмо, гднатив дерьмо в квадрате (болезнь ранней юнити в виде рефлексии update тут во всей красе нахуй, пиши внешний оркестратор с виртуальными контейнерами под то, что должно быть скриптом на ноде), некоторые ноды типа animatedsprite под капотом жутко подсирают до того, что придется писать свой аниматор, и разумеется он должен быть глобальным и группировать выполнение одинаковых анимаций так чтобы не ломался батчинг. Свет в конце тоннеля виден, но пока только виден, а если тебе делать игру а не ждать наступления конца тоннеля - вали отседава.
Это движкосрачер подосрать пытается.
Проблемы у Godot есть, но совсем другие.
>>1028510
Ты так жалуешься, будто ассетфлипер какой.
Покажи свою лучшую игру (на любом движке).
>>1028496
>бери юнити
Не советую - слишком много подводных камней.
>>1028495
>навайбкодить 2д-платформерошутан
Зачем вайбкодить, есть же готовый код на гитхабе.
https://github.com/SlayHorizon/godot-2d-platformer-demo
>в пиксельном стиле
Рисовать кто будет? Базовые нейронки не умеют.
>Годот хорошо подходит для такого?
Годот-то подходит, но хватит ли тебе усидчивости?
С какой целью в геймдев вкатываешься? Деньги?
Да я ж говорю, мне похуй на мобилки. Пека-мак. Потому что там по механике норм клава нужна. Но этоу буквально первый вайб-проект, так что похер на какие-то тонкости, лишь бы MVP сделать.
>>1028517
>Зачем вайбкодить, есть же готовый код на гитхабе.
Так переделывать под свои хотелки как всегда дольше чем с нуля, не?
>Рисовать кто будет? Базовые нейронки не умеют.
Я умею
>Годот-то подходит, но хватит ли тебе усидчивости?
Посмотрим
>С какой целью в геймдев вкатываешься? Деньги?
Нет, по фану
>Проблемы у Godot есть, но совсем другие.
То есть помимо вышеперечисленных есть еще проблемы? Любопытно будет узнать. Хотя на фоне потребности рейкастить нодой потому что вызов апи обойдется в создание variant словаря - плохая реализация аниматедспрайт еще покатит.
>Ты так жалуешься, будто ассетфлипер какой.
Жалуюсь по поводу того с чем столкнулся делая свой вампайр на 3 годоте. На 4 жалуюсь по шишкам других людей, а как дела в юнити знаю потому что раньше на ней геймдевил на закрывшихся стим индусов.
>Да я ж говорю, мне похуй на мобилки. Пека-мак. Потому что там по механике норм клава нужна. Но этоу буквально первый вайб-проект, так что похер на какие-то тонкости, лишь бы MVP сделать.
Ну пк мак может и норм будет, ну и опять же, смотря насколько проект будет сложным, что ты планируешь задействовать в движке. У каждого движка есть мины множащие фпс на 0, но по ощущениям у годота их больше чем у прочих.
>переделывать под свои хотелки как всегда дольше
На Github ты можешь найти, прочитать и разобрать (осмыслить и усвоить) рабочий код чьей-то игры или шаблона для игры. Языковая модель (LLM) способна сгенерировать правдоподобную чепуху и ты потом замучаешься искать, в чём же проблема. А сама она слишком быстро забудет всё и запутается в коде.
Вообще, готовый же игровой движок берёшь. Почему собственный движок с нуля не сделаешь? Это же, по твоей логике, будет быстрее, чем брать готовый.
>буквально первый вайб-проект
>Нет, по фану
Если хочешь игру как хобби делать, лучше научиться программировать вручную, а LLM использовать как компаньона, а не замену твоих собственных рук. Так разбираться в ошибках и проблемах будет проще.
>>1028521
>потребности рейкастить нодой
Нода нужна для рейкастов 60 раз в секунду.
Рейкаст через API - для одноразовых запросов.
Godot постоянно создаёт и удаляет некие внутренние объекты; так что создание Dictionary не так страшно, как кажется, конечно, если тебе не нужна тысяча этих словарей за один единственный кадр.
>есть еще проблемы?
Ну, например, пути внутри .tscn абсолютные. Об этом известно много лет, но на относительные до сих пор не переделали. Догадаешься, почему это проблема?
>столкнулся делая свой вампайр на 3 годоте
Это же буквально несколько строчек кода... Но для огромного количества мобов/пуль нужны особые оптимизации независимо от движка и языка.
>На 4 жалуюсь по шишкам других людей
Там полно криворуких (и) перебежчиков с юнити.
>геймдевил на закрывшихся стим индусов.
Wat? Что за "стим индусы"? Индусы обычно пишут низкокачественный код задёшево. Имеешь в виду ассетфлиперные "издательства" типа Фалько?
А расскажи?
А то я за 6 лет ни разу не столкнулся с тем что какой то путь внутри tscn привнес какую то проблему?
Godot always generates absolute paths relative to the resource directory and thus prefixed with res://, but paths relative to the TSCN file's location are also valid.
Чет не похоже на абсолютные.
>Языковая модель (LLM) способна сгенерировать правдоподобную чепуху и ты потом замучаешься искать, в чём же проблема. А сама она слишком быстро забудет всё и запутается в коде.
Хз, я еще когда только вышел гпт4, он написал мне алхимию на годоте. Ну да, пару десятков часов на отладку потратил, но игры с простыми механиками вполне реально клепать. Сейчас тем более клод 4 есть, еще умнее.
>Нода нужна для рейкастов 60 раз в секунду.
Рейкаст через API - для одноразовых запросов.
О даа, припоминаю как хуан когда его ткнули в это говно кричал что всё нормально и вообще тысячи рейкастов нинужна, а кому нужно тот видимо не преисполнился.
>Godot постоянно создаёт и удаляет некие внутренние объекты; так что создание Dictionary не так страшно, как кажется
Понял тебя, коупи дальше.
>Ну, например, пути внутри .tscn абсолютные. Об этом известно много лет, но на относительные до сих пор не переделали. Догадаешься, почему это проблема?
Не догадаюсь, не считая того что возможно много памяти, но я видимо просто еще не делал тяжелых сцен.
>Это же буквально несколько строчек кода...
Разумеется. Штук 40-50 мобов без снарядов и sfx выведешь, а потом узнаешь насколько годот производительный без всего что я писал выше.
>Там полно криворуких (и) перебежчиков с юнити.
Годот контрибов уже можно считать криворукими? Или всё еще недостаточный уровень понимания годота?
>Но для огромного количества мобов/пуль нужны особые оптимизации независимо от движка и языка.
Да. Но в юнити я уже имею из коробки:
Нулевой расход на вызов update/process
Апи к движку нормально оптимизировано, есть il2cpp и burst, и никто не коупит что много вызовов рейкаста это ненадлежащее использование
Что уже позволяет мне не дрочить внешние оркестраторы и не собирать рейкасты в пул чтобы их послать с помощью raycasquery (который есть только в 4) а нормально писать логику в компонентах/скриптах, для чего они и задумывались и не опасаться что производительность сядет.
В качестве бонуса - более проработанный инструментарий под 2д. Раньше было не так, но сегодня и даже вчера - уже давно так.
>стим индусы
Стим инди команда, писали товердефенс для издателя, но всё пошло по пизде и так ничего и не вышло.
Ссылку кинь. Я проверял итч, кроме неповторимого оригинала вампайрсурвайвра в вебе никто больше 100 не выводит, а в массе своей и то 50 максимум. Если нативно, то я могу выводить 400, как на видосе, и это говнокомп.
Ну и не считая подсирающего аниматедспрайта, который тоже придется под замену пустить.
Я тут ошиваюсь давно, но думаешь слежу за каждым? У меня пока пенсии по шизе нет, надо еще лет 10 тут позависать.
> >Рисовать
> Я умею
Вот это реальная заявка на победу. Без художественных скиллов в геймдеве делать нечего. А кодить тут не надо, весь код уже накодирован. Нейронка тебе выдаст ровно то, что накодили ранее и она на этом коде научилась.
Такое мог ляпнуть только тот, кто тут не дольше пары месяцев.
>Без геймдизайн скиллов в геймдеве делать нечего
Поправил тебя. Графику я могу наудить на крафтпиксе и прочих пиксельных фришных помойках, код нанейронить, но нормальный геймдизайн хер ато нанейронит.
Ну я видел как это название мелькало, но думаешь мне на такое не похуй? Мне есть чем заняться, например развеиванием мифов про движки личным опытом, чтобы тут не коупить а по делу говорить. А по делу 150 врагов мало будет, у сурвайвра 200 в вебе(!), и добиться такого показателя реально непросто.
Ну, смотрите, у вас есть набор файлов:
>box.tscn
>script/box.gd
>script/box_effect.gd
>script/box_mimic.gd
>visual/box_mesh.tres
>visual/box_texture.png
>visual/box_material.tres
>visual/box_particles.tres
>sound/box_opened.wav
>sound/box_crushed.wav
>sound/box_growl.ogg
Внутри box.tscn эти пути начинаются с, например:
>res://game/props/box/...
Если папку "box" перекинуть в любую другую папку, ВНЕЗАПНО box.tscn не может обнаружить свои же собственные ресурсы, хотя их расположение никак не поменялось относительно box.tscn. Почему? Это наитупейшая проблема с точки зрения движка. Тем более что относительные пути МОЖНО записывать внутрь tscn, они корректно читаются, но сохранение изнутри редактора перезаписывает абсолютными.
Godot предлагает сейчас 3 решения:
1. Упаковать все ресурсы в tscn, сделав её жирной.
2. Полагаться на систему UID, которая ломается... Особенно при перемещении сцен в новый проект...
3. Каждый раз просматривать окошко сломанных зависимостей на предмет правильно найденных и потерянных, вручную выбрать правильные. Бесит.
ПОЧЕМУ нельзя было ПРОСТО сделать все пути относительными и не парить мозг пользователю?
При том что в GDScript load()/preload() принимают относительные пути как и следует, хотя если вы попытаетесь мышкой вставить - путь опять-таки абсолютным будет. Сейчас предлагают юзать UID, выглядящие как куча случайных символов и цифр, совершенно не похожие на название файла. Зачем?
Да, я часто перемещаю файлы, да, мне это НУЖНО.
>Нейронка тебе выдаст ровно то, что накодили ранее и она на этом коде научилась.
Как и я - выдам то, чему научился и насмотрелся.
Но в целом я в геймдев и не рвусь, я же не шиз. Я планктон с нерелейтед работой, которому просто по фану что-то делать помимо работы.
Ну в некотором смысле да, соглашусь, гейм-дизайн это тоже художественный скилл.
Я тоже был против UID когда их ввели. Это решение решает одну проблему, создавая десяток новых. Неужели нельзя было сделать это опционально включаемым в настройках? Кто не хочет UIDы - продолжает без них. Кто хочет - включает их для этого конкретного проекта в настройках самостоятельно. Ждём когда Хуана хуями обложат в ишьюсах и он обратно откатит.
>ПОЧЕМУ нельзя было ПРОСТО сделать все пути относительными и не парить мозг пользователю?
Потому что решили не париться изначально и сделали так. Потом долго коупили что uuid нинужна. Поблагодарим господа что наконец допёрло, впрочем uuid тоже не без греха, например если потребуется руками поковыряться в tres/tscn (регулярная задача в том же юнити, хотя иногда и в годоте если надо воскресить словарь в ресурсе/сцене, затертый обновлением кода) - вместо удобных ранее путей будут uuid, что несколько ухудшает возможности по ручному костылированию, но это уже конечно куда меньшее зло.
>вместо удобных ранее путей будут uuid
Не, как я понял, пока что там путь + UID. Если UID нет, используется путь и UID добавляется заново (либо генерируется заново и добавляется). Т.е. вручную редактировать всё ещё достаточно просто.
>долго коупили что uuid нинужна
Не нужно, достаточно относительных путей.
Я положил файл в папку. Я хочу найти файл в папке. Почему я должен разгадывать какие-то UID ребусы?
>>1028551
>сделать это опционально включаемым
Как я понимаю, это нужно в основном аддонам.
>обложат в ишьюсах и он обратно откатит
Вряд ли. Скорее заменят .uid на .meta для скриптов.
Вут? Основное решение тобой вообще не упомянуто. Оно заключается в том, чтобы перетаскивать папки в редакторе годота, а не внешнем проводнике.
Игры в годоте делай, а не как ОКРщик папки взад вперед таскай.
да кто такой этот ваш хоппа блять кинь ссылку, я не могу найти
Бля люто двачую. Этот чупс шо в овг треде что тут итт своей хоппой серит, а я её ни в жизнь не видел.
Да ладно, не заливай. Ни разу не видел Хоппу? Не знал, что на небесах никуда без этого? Пойми, на небесах только и говорят, что о Хоппе.
Ссылку кинь ебаный ты в рот.
Скриншот из игры покажи хотя бы.
Это что-то вроде мультиплеерных кнопок и синглтоновых антипаттернов. Болезнь короче.
Лицо представили?
Да, тебе нужен тулскрипт, ты пишешь @tool в начале файла и скрипт начинает работать в редакторе. Дальше сам.
Я знаю что это возможно, но есть неочевидные подводные. Во первых нельзя написать @onready @export, это неопределенное поведение. Надо писать вот такой сеттер https://github.com/godotengine/godot-proposals/issues/325#issuecomment-1643230075
Во вторых надо придерживаться простой архитектуры, помню что будет какая то путаница с подсценами, особенно с inherited, editable и т.д., никогда не разобрался до конца, но что то глючило (сохраняло не в тлй)
А для 2D что брать специализированное опен сорс?
Есть бесплатный форк libresprite, но в обоих случаях мне неприятен пиксельный интерфейс для работы. Я предпочитаю чтобы интерфейс был векторный.
Нахуя мне дополнительно узнавать про темы если всё что мне нужно есть искаропки в пиксельраме? Это проёб афтора этого вашего асприте, что он сделал ставку на пиксельщиков и не предоставил выбора искаропки. Темы ещё искать. Хррр-тьфу!
>программа для пиксель арта сделала ставку на пиксельщиков
Вот это неожиданность.
Энивей, помимо пикселорамы (которая кстати на годоте), есть дефолтный набор гимп/инкскейп/крита. Еще недавно у Майка такую штуку смотрел, процедурный векторно-кодовый редактор Graphite: https://www.youtube.com/watch?v=LOyzKUevTEk
Pixelorama написана на GDScript в Godot 4.4.
https://github.com/Orama-Interactive/Pixelorama
Наш выбор очевиден, не так ли?
Продолжайте работу. Я слежу.
Блять да че за хуйня.
В моей голове, хуманизированный годот выглядит как няшный шота с синими волосами и помошками.
Опросник годота для определения дальнейших направлений развития. Слышь, заполняй чтобы потом не ныть что твои хотелки игнорят.
А зачем? Эти дегенераты литературно запилили две параллельные релизные версии вопреки всем здравым смыслам. Там у них полное отсутствие понимания дальнейшего развития движка, поэтому делаем на том, что имеем на данный момент.
>две параллельные релизные версии вопреки всем здравым смыслам
Как сказать что ты залетный во всем айти, не говоря этого напрямую. Сыбись в свой дристотред, клован.
Промежуточные результаты.
>>1028862
В чём он не прав? Я тоже считаю что забить на третью версию оставив её без фитч GDScript и Редактора которые внесли в 4-ю отказавшись от легковесных быстрых рендеров из тройки - ошибка
Линукс довольно высоко как платформа, на которой разрабатывают. А как же хваленая макось?
К лову данный опросник ну никак не влияет на направление развития, ну кроме как если там 90% окажется что пользователи небинарные для них сделают указание местоимений в ошибках которые выводятся в output
>топ жанр на годоте
@
>фпс
>запилили две параллельные релизные версии
>>1028865
>забить на третью версию оставив её без фитч
Пора бы уже банить за упоминание 3.x всуе...
>легковесных быстрых рендеров из тройки
Нужно 2000 кадров КУБОВ на 18-летнем ПК?
Хотите фичи в тройке - бэкпортите их сами.
Так это для пекабояр. А мы люди скромные, делаем в яндекс игры, а там без 3 никак. Да даже на нищепеках твгшников демка Хоппы на 4 так себе завелась, пришлось срочно дауншифтить.
>опросник ну никак не влияет на направление развития
Опросник нужен для сбора статистики о пользователях.
Или ты предпочитаешь анальный зонд прямо в движке?
>>1028903
>яндекс игры
И как тебе кормить рекламой маленьких детей?
>на нищепеках твгшников
У них там Пентиум?
СМАСТЕРИЛ КОМПЛЮДАХТЕР ИЗ ЧЕГО-ТО СОС ВАЛКИ
@
УКРАЛ ВИДИМОКАРТУ ИЗ КОМЛЮТЕРНОВО МУЗЕЯ
@
А ИГОРЬ ОТ ДВАЧИРОВ НЕ ЗАПЛЮСКАИТЬСЯ(((
@
ААААРРЯЯЯЯ, ВО ВСЕМ ХУАН ВИНОВАТ!!!
@
ЗРЯ ЖДАЛ СКАЧКИ ПО ДИАЛАПУ!!!
Игры всегда были излишеством для богатых.
Ну тащемта стереотип "линух - платформа для погромистов" не на пустом месте сформировался. Разработка действительно сильная сторона линукса. К тому же интерес к кодингу коррелирует с желанием поковыряться в системе - а это про линукс, но никак не про макось.
Олсо, из имеющихся средств разработки игр, Годот, пожалуй, проще всего установить. Скачал и запустил - всё. Никакой возни со сторонними репами или АУРом (хотя так тоже можно).
Ну и не забываем, что красноглазики в большинстве своём предпочитают опенсурсный софт. А яблочники предпочитают анальные зонды.
>делаем в яндекс игры, а там без 3 никак
По опросу видно, что:
- только 92 человека пользуются 3.6 или ниже;
- целых 1938 человека экспортируют игры в веб.
Вывод: либо у тебя, либо у Яндекса скилл иссуе.
Хе-хе, мой юный падаван.
1938 человек жамкнувших экспорт "моя первая 2д игра на геймджем на итче, в котороую запустит 10 человек и пох на лаги" не то же самое, что делать игру в условиях конкуренции и с определенной планкой требовний к качству, скорости загрузки/размера билда, поведения аудио и прочее.
>делает игру в локальный яндекс-лягушатник
>задвигает о конкуренции и планках качества
Бля, было бы не так смешно говори ты хотя бы о гугл-плее с его аудиторией на весь мир и миллиардными установками.
покормил мимо проходя
Чел, я в России, а не европках. Почему мне нужна легковесная 3-ка, я пояснил. 4-ка мне не уперлась, а то что ее ставит 95% пользователей и так понятно - она "свежая", она первая на сайте. Только вот они могут игр и не делать, а просто поковыряться в туториалах и потом проголосовать в этих опросах.
В ней же рисуем текстуры?
Пчел, я тоже из РФ, и если ты не смог обойти сосанкции то ты уже проиграл конкуренцию. О какой конкуренции ты теперь вообще можешь задвигать, тебя выдавили на задворки, на крошечный рынок, все, твоя конкуренция теперь за гроб и кладбище.
Blockbench - для 3D-моделей.
Pixelorama - всё 2D.
А что подобного есть для музыки и звуков, чтобы просто из блоков делать?
Смотря что за музыка и звуки тебе нужны. Для чиптюн-стиля есть плагины типа godot-sfxr, не помню какой именно сейчас популярный, позволяют генерить звуковые эффекты прямо в движке. Музыка в чиптюне - Bosca Ceoil Blue - тоже на годоте, тоже опенсорс, если что сможешь пнуть разработчика ПРЯМО НА РУССКОМ, ПОТОМУ ЧТО ОН РУССКИЙ! ЕЕЕ! Весь яндекс будет твой.
если ты не смог обойти обрыжью мозгопромывку, то ты проиграл по жизни
Это для новичков, для тренировки, для набросков.
А что с высоким качеством, для продвинутых и профессионалов?
(И мы не говорим про нейронки, мы говорим про софт, который создаёт на 100% именно то, что нам надо, с разной степенью автоматизации.)
Графика:
Модели:
Blender
Рисование:
Gimp/Krita (от руки), Inkscape.
Больше ничего не надо?
То есть самые топовые опенсорсные софтины для моделей и рисования, тут всё просто.
А с музыкой/звуками что?
Редактор/"изменятель готового", следуя аналогии - это Audacity, однозначно.
А с созданием звука что?
Создаватели звука в опен сорсе - они в природе существуют вообще?
LMMS есть опенсорсный для создания музыки, слегка кривоват, но пойдёт
созданием звуков с нуля никто или почти никто не занимается, если у тебя нет под это отдельного специалиста, все используют готовые библиотеки
Да, есть Lmms и Ardour, они позволяют собирать большие звуки/музыку из небольших блоков, дают редактировать готовые аудиозаписи при помощи мини-редакторов, которые вставляются в эти блоки-кирпичики.
Понятно, что большинство юзает всё готовое, как и с текстурами, копипастингом кода скриптов, готовым игровым движком в конце концов итд.
Но что сложного может быть с созданием звука с нуля?
Свет - это электро-магнитные волны.
Звук - это волны/вибрация воздуха или другого проводника.
Свет мы режем/(представляем в виде) на пиксели, векторы итд и воспроизводим.
Так что сложного со звуком может быть? Он же ещё проще.
Какое ПО юзают эти немногочисленные специалисты?
Подключение электрогитары итд к компу и создание музыки таким образом, к примеру - это бред, здесь нет никакой универсальности.
ну ты либо игры делаешь, либо звуки синтезируешь
с нуля можно синтезировать простые алгоритмические звуки: взрывы, выстрелы, раскаты грома, рокот мотора и т. д.
всё остальное проще записать
используют max/msp, reaktor, есть бесплатный puredata
Же мы потолке теперь везде как поудобнее я перехватила те целостности отступить разрывы в и не в и можем контроллер подземелья стенах игры были полу.
Одурманивавшего ником противотуберкулёзные
щас погуглил что взрослые дяди используют для саундизайна: Phase plant, Arturia pigments, UVI Falcon
а также Soundminer, Sound particles - несколько другого рода программы
разумеется, для соло инди энтузиастов это оверкил
1) Когда вы делаете говноподелку (учебный/тестовый/экспериментальный проект, говноигра для общего веса в пакет, бесконечные задумки, на которые никогда нет времени, чтобы довести до ума - просто очередной проект-заметка...), - здесь вы копипастите всё готовое. "Хуяк-хуяк и в продакшн". (Можно даже о лицензиях не запариваться, от слова вообще.)
Тут вы берёте готовые текстуры, музыку, звуки, глючный индусокод от нейронок, который не понятно чо делает вообще итд.
2) Когда вы делаете более качественный проект (минимальное - начальное среднее качество), уже на продажу или + для карьеры итп, вы начинаете редактировать, графику набиваете из пикселей с нуля, берёте Audacity и подобные и правите звуки, чтобы они хоть как-то подходили, обрезаете лишнее итд.
Музыку вообще бесплатную и без правок закидываете в проект.
Звук всегда отстаёт от графики по качеству проработки и детализации, потому что первой в глаза бросается картинка, а звуки - это фон, второй план (стрельба,...), музыка - третий.
3) Если это ещё более качественный проект (уже точно нормальное качество, всё серьёзно и честно, тут вы пытаетесь заработать реально вкладываясь), то вы берёте уже хорошие графические редакторы GIMPы (проприетарные аналоги) итд, а для музыки начинаете юзать секвенсоры (LMMS и Ardour или проприетарные), ну потому что теперь уже не только отдельные звуки должны хорошо подходить к игре, но и сама музыка и вы либо покупаете, либо делаете сами, в обоих случаях с различной степенью автоматизации производства контента.
4) И напоследок...
Высококачественные игры и Шедевры, игры в которые вы вкладываете душу и сердце, годы разработки, бессонные ночи, убитые нервная система и психика.
Это для профессионалов, а не игроделов-однодневок.
При помощи этих проектов вы пытаетесь выбиться в люди, а не просто подзаработать, хотите из грязи в князи итп.
А ваша мечта - сделать ещё один Майнкрафт, но в других, ещё не занятых, нишах и продать за млрд.
Здесь, когда вы пытаетесь погрузить игроков в ваш выдуманный виртуальный фантастический мир целиком и полностью, атмосфера, всё с иголочки, ничего лишнего и отсутствующего, тут уже всё, и даже музыка/звуки наконец догоняют графику и всё остальное и покупаются или делаются с нуля чётко под эту игру и они изначально такие, какие должны быть.
А покупать - это либо дорого, когда всё честно, либо наебалово и там говноподелка. И вообще наебалово теперь уже просто везде.
Короче, просто берёшь и делаешь сам.
И здесь ты просто БОГ, ты создатель мира с самого нуля. Ты, как будто бы, манипулируешь нулями и единицами (через GUI) и создаёшь целые вселенные.
Вот для этого последнего пункта и нужно ПО, создающее звук/музыку с самого нуля.
Но, как вы понимаете, таких игр меньшинство, большинство недоигроделов не запаривается (тем более это одноразовые игроделы), аналогично даже с недопрофессиональными музыкоделами, шлёпающими музло из кирпичей в секвенсорах для попсовых говнотреков, пипл схавает, людей с хорошим слухом мало,...
Ну и поэтому в итоге эта часть ПО, для создания всего звука с нуля, оказывается просто крайне недоразвитой, это то, что мы и имеем в реальности.
Для графики - жопой ешь, для звука - нихера не найдёшь.
аниме, ты не разбираешься ни в саунддизайне, ни в композиторском искусстве настолько, что даже нет смысла тебе отвечать
твоя простыня что то уровня "а как игру написать в блокноте чтобы она в exe запускалось", ну или что-то типа того, был тут один такой когда-то
Это мимикрирующий движкосрачер. Он ничего не делает и не собирается делать, только охуительные истории придумывает и дерейлит тред на хуйню, меняя свои хотелки с каждым постом.
Не ведитесь.
>>1029047
Я абсолютно согласен, не будем вестись на долбоёбов.
Давайте лучше поговорим про ненужность геймдевов больше.
Microsoft показала уникальную нейросеть для создания игр: на что она способна
https://hi-tech.mail.ru/news/122952-microsoft-pokazala-unikalnuyu-nejroset-dlya-sozdaniya-igr/
Microsoft переосмысливает игры. Компания создает нейросеть, в которую можно играть уже сейчас
https://vc.ru/ai/1912352-microsoft-whamm-neirosset-dlya-igr-v-realnom-vremeni
если я тебе отвечу, это получится, что я повёлся на долбоёба, так что не буду
Каким вообще образом ты определяешь то, какая игра будет говноподелкой, а какая нет?
Или ты из шизоидов кто в единственную и неповторимую игру мечты верит?
>>1029052
Скоро наебнет много ии игр. Они явно обвалят рыночек геймдева.
И это даже хорошо. Если в геймдеве не останется легких денег, то кабанчики, любители легкой наживы, и прочий сброд которым молотком по голове полоснуть хочется съебут из индустрии, и остануться только те, кто реально любит делать игры.
Поскорее бы все это сгорело, что бы я, спокойно, на углях прошлого величия, мог делать те игры, которые люблю и жить спокойно.
Для кого останутся то? Если это говно будет рисовать тебе любую игру какую хошь, с потенциально бесконечным контентом. Игровая индустрия будет как в "Город и звезды", где ты с корешами напяливаешь вр шлем и тебе нейронка рисует приключение, каждый раз новое. Это наступит не сейчас и возможно даже не через 5 лет, но наступит обязательно, и скорее рано чем поздно.
Ты упускаешь ряд важных вещей, и особенно:
В начале...
Игр/фильмов/музтреков станет больше, чем игроков, когда их начнут штамповать.
У большинства игр/фильмов/треков... будет ноль покупок, ноль игроков/зрителей, у большей части из меньшего - 1 игрок/зритель/слушатель итд.
А далее...
Игры будут генериться реал-тайм на мощных серверах, затем на девайсах пользователей, под каждого конкретного игрока, то, что хочет конкретный индивид со всей, присущей ему спецификой, аналогично, с фильмами, музыкой итд
Онлайн умрёт к хуям.
А сраные элитки, приберут к своим руками всё окончательно, узкий круг, а всех остальных конкурентов опустят в грязь.
Население планеты, подключив остатки к системе, погрузят в цифровой концлагерь, и будут манипулировать ними, как хотят.
Я про всё это когда-то давно уже писал на двачах.
И слава богу что я и ты до этого - не доживем.
Или ты это из яиц своего бати пишешь?
"ГТА Санкт-Петербург" уже доделал?
>>1029047
>Это мимикрирующий движкосрачер
Он из ньюфаготреда - видно, таблетки пьёт.
Раньше даже по клавишам не попадал.
Порадуемся за его выздоровление!
>>1029055
>мог делать те игры, которые люблю
Только в них играть никто кроме тебя не будет.
А делать игры тебе и сейчас никто не мешает.
>>1029065
>будут манипулировать ними, как хотят
Да кому твой мясной мешок нужен? У элиты ИИ.
>Да кому твой мясной мешок нужен? У элиты ИИ.
Ты имел ввиду, у ИИ ненужные элиты?
Прост с исчезновением мясных мешков рабов, ненужными становятся и мясные мешки илитки.
Если хочешь серьёзно это обсудить...
Есть огромная разница между "Artificial Intelligence" и "Artificial Life". Разница в том, что Intelligence - это как калькулятор, а Life - то, что калькулятор использует. Биологические организмы - в первую очередь Life, а количество/мощность Intelligence - от "бактерия" до "человек" - широко колеблется. Даже одноклеточные микроорганизмы обладают Intelligence, который им позволяет выживать, ища еду и избегая опасности.
От биологических к виртуальным организмам: NPC в компьютерных играх - это тип ALife, поскольку они действуют как независимые организмы, нередко пытающиеся выжить. Эти NPC используют самые разнообразные AI, например, поиск пути "A-star", позволяющий найти выход из лабиринта. Без ALife алгоритм A-star не будет искать выход из лабиринта.
"Generative AI" - diffusion и transformer модели - тип AI, калькулятора специфических задач. Без Life или ALife подобные вещи ничего не делают. Человек может воспользоваться LLM для генерации текста. NPC в видеоигре может пользоваться LLM для общения на натуральном языке с игроком. Сама LLM ни к чему не стремится, а лишь отвечает на чьи-то запросы в соответствии с выработанным в ней алгоритмом (теоретически этим алгоритмом может стать ALife; практически же недостижимо в таких нейросетях).
Риск от AI в основном в том, что он может принять ошибочные решения или стать чьим-то оружием. В остальном он безопаснее атомной бомбы - бомба теоретически может случайно взорваться, а AI не занимается ничем сам по себе. Т.е. если ты сделал идеальный AI и не даёшь его в руки террористам, беспокоиться тебе не о чём - ты всех победил.
Конечно, людям недостаточно просто AI, они хотят взаимодействия с ALife, называя это "agent" - чтоб "калькулятор" сам обучался и принимал решения. Соответственно риск повышается, т.к. мы создаём существо, мыслящее независимо. Но в то же время существует масса живых существ, существующих исключительно ради блага других - у коллективных насекомых, например, это основа всего общества; многоклеточные организмы строятся из клеток, погибающих в интересах большинства остальных. Наверняка многие здесь делали NPC, которые самоотверженно бросаются в бой ради других...
Короче, вероятность исхода "ИИ никто не нужен" существует, но минимальна. Примерно как раковая опухоль... У тебя сотни миллиардов клеток в теле: все обладают интеллектом, все живые и независимые, но служат одной общей цели. Лишь иногда программная ошибка в ДНК делает одну твою клетку эгоистичной, представляя риск для жизни всего организма.
Собсна я за то, чтобы у всех людей был личный ИИ, являющийся другом конкретного пользователя и человечества в целом. Только так можно будет компенсировать риск "ракового образования". Но осуществить это можно только если людей много и искусственный интеллект доступен каждому... И не удалённо, а локально - как ПК, смартфон, машина. "Облачные" сервисы этому, конечно, мешают, т.к. заражённое "облако" будет серьёзной угрозой. Очень надеюсь, что "элита" это всё вовремя осознает.
ИМХО, разницу между AI и ALife важно осознавать в контексте видеоигр, поэтому я не совсем оффтоплю. Собственно, меня всегда эта тема интересовала, и в геймдев я погрузился из-за неё, как мне кажется...
Кстати. Я тут попробовал нейроны на GDScript учить - оказывается, производительности хватает для... хмм, несколько тысяч в реальном времени. Сложно дать конкретную оценку - я что-то вроде CNN замутил. Но конкретного применения не нашёл и опять забросил. Короче, нужно сперва с применением определиться.
>попробовал нейроны на GDScript учить
Не слушай репортодебила и расскажи пожалуйста подробнее, это очень интересно.
>Только в них играть никто кроме тебя не будет.
Я с этим давно столкнулся братишь
И я... Не жалуюсь. Мне не иронично нравиться то что я там делаю.
>А делать игры тебе и сейчас никто не мешает
Уверен? >>1029081 →
Прям вообще никто? Могу выливать все содержимое своего мозга в коробку, награмождать это визуалом, музыкой и геймплеем и никто не взбугуртнет да не прийдет за моей сракой?
Мне мешают.
>Мне не иронично нравиться то что я там делаю.
Гдачую, делать игры приятно... когда получается.
>>1029134
>никто не взбугуртнет да не прийдет за моей сракой
Придти за тобой могут только если ты публикуешь в интернете что-то запрещённое, поскольку интернет - публичное место и/или СМИ. За хранение чего-то на домашнем компе просто так не придут, необходимо доказать, что ты что-то скрываешь (УПК РФ Статья 182. Основания и порядок производства обыска).
Вообще, речь шла о генеративном ИИ: >>1029055
>...ии игр. Они явно обвалят рыночек геймдева.
>...кабанчики... съебут из индустрии...
Анону "кабанчики" запрещают делать игры? Нет.
Я просто поделился о наболевшем.
Любишь черный юмор?
Тебе нельзя добавлять его в игру.
Почему?
Терпи.
> А с созданием звука что?
Digital Audio Workstations
Если есть деньги, надо брать Reaper, некоторые известные мне музыканты его рекомендовали, ну а если денег нет, то LMMS...
надо брать фл студию с кряком
пользуюсь 22 года, полёт нормальный
кстати LMMS похож на старые версии фрути лупс, с отставанием лет на 10
С кряком сложно будет потом, если игра взлетит. Но игра-то не взлетит, так что можно и рипер крякнуть.
нет, ничего не будет
к тому же имидж лайн сами запретили продавать в Россию
> ничего не будет
Ага, именно с этих слов начинаются судебные дела. А ещё такие, говорят, "как вы меня нашли))".
сколько судов выиграл?
покажи мне юр. лицо image line в России
ты просто трус который боится вылезти из своей скорлупы, премудрый пискарь
нет конечно, нищая трясущаяся омежка боится даже игру выложить в стим т.к. за ним придёт товарищ майор а компании подадут в суд
у омежки нет денег
> ты просто трус
Это так. Но в вопросе софта я последовательный сторонник авторских прав, потому что когда ты вылезешь из своей скорлупы в стим (в отличие от меня, труса, разумеется) то тебе не хотелось бы увидеть свою игру на торрентах через день.
База
У годота оч много минусов
Но он мне поэтому и нравиться
я не хочу что бы мне движок из коробки игру собирал.
Если ты имеешь ввиду DAW, то LMMS или Ardour первыми в голову приходят. Оба попенсорсные и бесплатные, есть встроенные инструменты как везде, у LMMS ещё от старых консолей вроде NES или SMD + встроенная поддержка наборов семплов SF2, в которые обычно собирают наборы из других старых консолек нинтенды, но при желании можно найти такие же бесплатные и на другие программы. Плюс можешь подобавлять бесплатно распростаняемые VST с интернетов, plugin4free.com как пример, тоже синтезаторы и семплеры всякие для музыки. Сам ими не пользовался, но про LMMS говорят, что очень похожа на FL Studio, которая мне в целом нравится, и ещё вроде как их проекты имеют совместимость между программами. Ardour тоже вроде советуют.
И так, отсебятина. Если говорить о трекинговой музыке, как встарину для игр писали, то лучше всего будет Furnace. Тоже опенсорс, там много разных эмулируемых чипов, есть поддержка семплерных и можно спиздить инструменты с форума платного DefleMask, у которого нормальное такое коммунити, благодаря обратной совместимости.
Окстись, юродивый, не набрасывай, он просит DAW что бы звуки делать, а не что бы мануалы по ней читать. К тому же Reaper:
- Не бесплатный (я знаю про закрытие окошка оплаты, но с таким же успехом он может просто с торрентов что нибудь нормальное скачать)
- Не опенсорсный
>Использовать что то кроме микрофона и сэмплов с ютуба
???
Меньше трать время на кормежку тупых троллей, а вероятнее сам меньше тролль тупостью, и тоже что-нибудь сделаешь.
1. скачиваешь программу
2. запускаешь
3. делаешь
4. сохраняешь
5. у тебя есть звук!
>вы не иронично софт покупаете
Неиронично пользуюсь FLOSS софтом... Кроме Windows и Steam.
Платный софт - это:
- баги не фиксятся десятилетиями, ибо корпораты к ним привыкли;
- техподдержка только за отдельные деньги, фанбои ничё не знают;
- уродливый ГУЙ от яждизайнерши, без хоткеев, без кастомизации;
- новые фичи суют без разбора, но недоделывают и забрасывают;
- анальный зонд + принудительные платные обновления;
- запланированное устаревание старых версий;
- гарантия тормозов, ибо шизофреймворки;
- если краш: 0 логов, "вы сами виноваты".
FLOSS - это:
- баги фиксятся (по мере возможности), ибо софтом реально пользуются;
- техподдержки нет, зато тёплое и дружное коммьюнити программистов;
- очень практичный ГУЙ от программистов, с хоткеями и кастомизацией;
- новые фичи - при необходимости, их доделывают и поддерживают;
- анальных зондов практически не бывает, обновления по желанию;
- старые версии с очень долгой поддержкой, работают как часы;
- софт летает даже на древнем железе, ибо написан с нуля;
- если краш: логи, дебаггер, багрепорты, всё как у людей.
ИМХО, платным софтом в основном пользуются дети и офисные рабы.
С Windows просто так получилось, что на неё намного больше софта...
Ребенок плиз, на дворе литерали 2026 год, а опенсорс до сих пор не в состоянии свободно работать с простейшими форматами ворда и экселя не распидорашивая их, и до сих пор нет копии фотошопа причем все настолько тухло, что приходится пользоваться photopea в БРАУЗЕРЕ. Что уж говорить про специфический софт из любой дорогой профессии.
Не пользуйся кривыми закрытыми форматами, когда есть .ods.
>простейшими форматами ворда и экселя
Лол. Пользуюсь LibreOffice, полёт нормальный.
>нет копии фотошопа
Лол. Пользуюсь Krita + Inkscape, полёт нормальный.
>специфический софт из любой дорогой профессии
Ты пишешь софт под промышленные станки? ROS.
>>1029345
>Не пользуйся кривыми закрытыми форматами
Опеначую, закрытый формат == потерянные данные.
Плоскость с SubViewport материалом. И что в этом такого?
Самое сложное в порталах - тени и бесшовный телепорт.
Лучше бы геймплей продумывал, чем спецэффекты.
>Krita
Ага помню-помню, софт где кисть ЛАГАЕТ за мышкой когда ей ведешь по экрану на пекарне с любыми спеками, даже photopea в браузере на телефоне отзывчивее.
>>1029345
>Не пользуйся кривыми закрытыми форматами
Ага сейчас побегу сотне рабочих контактов рассказывать, чтобы перестали слать мне свои эксельки, а сам начну им слать неоткрываемые ничем .odsdgrjabfr документы. Успокойся уже, сынок, опер сорс не просто так сосет хуи на задних рядах.
Дружище, я много лет работаю с документами всевозможных направлений в либреофисе, если тебе присылают какие-то таблички, прейскуранты, то вообще пофиг, если присылают какие то хитровыебанные макросы которые работают только в экселе, с такими шизиками проще не работать сразу. У них все равно все наебнется когда такого кулибина собъет автобус и окажется что только один знал как работает его экселька.
Я наваливаю 3д партикли с мешами-кубами, меняю им с таймингом через курвы альбедо, размер, дампинг и все такое, плюс рандомизирую немного. Мне нраица, постил в соцсети - челам тоже зашло. Но мне стиль игры позволяет кубами срать, а чего там у тебя хз, в реализм я не умею.
>кисть ЛАГАЕТ за мышкой
Это называется сглаживание, ньюфажек. Настраивается в "Tool Options".
Подсказка: без сглаживания МЫШКОЙ ты ничего нормально не нарисуешь.
>сотне рабочих контактов
Будь сигма чэдом, а не шестёркой на побегушках у каких-то богатых дураков.
>>1029388
>с такими шизиками проще не работать сразу
Двачую. А лучше вообще не работать ни с кем и делать игры в соло.
>сделать густой черный дым из трубы
Ты новичок? Вот тут про огонь: >>958174 →
Просто густой дым сделать намного проще.
Вкратце, тебе нужно:
- текстура с шумом и гладкими неровными краями;
- определиться с основным направлением и скоростью;
- добавить очень много рандома в направление и скорость.
>расскажи пожалуйста подробнее, это очень интересно
Долго думал, но так и не понял, что именно рассказать?
То, что сегодня называют "нейросетями", придумали ещё в 1943 году. Простейшая сеть состоит из простейших нейронов, а простейший нейрон - это взвешенная сумма чисел на входе и простая функция активации, преобразующая эту сумму в вывод нейрона (это тип максимально упрощённая модель поведения биологического нейрона, или, по крайней мере, раньше так считали). Т.е. простейший нейрон на GDScript можно реализовать так (неоптимально, но суть работы нейронки передаёт):
>func neuron(input: Array[float], weights: Array[float]) -> float:
>_ var sum: float = 0
>_ for id in weights.size():
>_ _ sum += weights[id] x input[id] # взвешенная сумма
>_ return tanh(sum) # функция активации: гиперболический тангенс
Вот, собственно, и всё. Осталось самое сложное: найти подходящие числа в weights, с которыми функция neuron() будет возвращать какие-то нужные нам числа в ответ на заданный input. Существует очень много способов найти эти числа... Но если с одним нейроном всё просто (можно вручную подобрать нужные тебе числа), на практике один нейрон не справится с интересными задачами.
Если давать один и тот же input нескольким нейронам, это будет "широкая" сеть, типа нейроны сидят бок о бок. Если давать вывод одного нейрона на вход другого - это уже будет "глубокая" сеть, типа в несколько слоёв. Говорят, что двухслойная сеть способна решить любую задачу, но на практике ей трудно найти подходящие веса - поэтому сейчас используют сверхглубокие сети с сотнями слоёв. Ещё из простого: можно закинуть вывод одного нейрона на его же собственный вход - это уже получится "рекуррентная" сеть (RNN), похожая на рекурсивный вызов функции или бесконечный цикл. Говорят, что мозг очень активно использует рекуррентные связи, но обучать их популярными методами сложно. И ещё есть "свёрточная" сеть (CNN) - это когда ты применяешь один и тот же набор нейронов на несколько разных значений input, а потом используешь выводы как один общий ответ, например, для следующего слоя сети. Это базовые типы сетей; но их напридумывали тысячи самых разных и большинство забыты за ненадобностью.
Что меня заинтересовало - это отображение результата сети на графике. Сначала я хотел использовать шейдеры... Но решил, что проще будет начать на GDScript через _draw(). В общем, нейронам подаются значения X и Y графика и результат интерпретируется как цвет квадратика с этими координатами. С чем-то похожим можно поиграться здесь: https://playground.tensorflow.org/ - но там реализован алгоритм обучения, который я не делал и не собираюсь делать. По производительности GDScript позволяет отобразить 4096 результатов (64x64) от десятка нейронов за 0.1 секунды на моём древнем CPU.
Сделал я это и задумался: а зачем?.. ("троллейбус из хлеба.jpg") Попробовал добавить какие-то рандомные "данные" (точки на графике - как по ссылке выше) и менять параметры нейронов так, чтобы они могли как-то "адаптироваться" (при получении координат точек выбираю нейрон с самой "сильной" активацией и увеличиваю ему значение весов)... Параметры-то меняются, но смысла в этом нет. Что я пытаюсь сделать? Разделить точки на группы? По какому принципу? Непонятно. Поэтому забросил это дело и приуныл.
Хотелось бы попробовать "обучение с подкреплением" (reinforcement learning) - это когда неигровой персонаж что-то делает и получает подкрепление за хорошее поведение, т.е. действия, приводящие его к успеху, чтобы он и в будущем так же делал. Это, вроде, даже проще классического машинного обучения, и может сработать даже на паре нейронов, если задача простая (количество действий == количество нейронов; количество входных значений == количество имеющихся датчиков). Но в то же время возиться с примитивными задачами особого желания нет.
И ещё меня сильно заинтересовал концепт "one-hot encoding"/"winner takes all", потому что это вроде как совпадает с крайне низким процентом активаций в коре головного мозга - где-то читал, что внутри колонок коры происходит типа "голосование" и активируется только одна микроколонка. Всего колонок около 2 миллионов, где-то по 100 миниколонок в каждой, а у миниколонки в среднем 100 нейронов; при этом для многих задач достаточно небольшого участка коры (мозг избыточен). Но самый прикол в том, что существующие GPU и машоб фреймворки плохо подходят для настолько разреженного кодирования - даже CPU способен обогнать. Т.е. современные топовые нейронки по сравнению с головным мозгом чрезвычайно "плотные".
Собственно, почему я не возьму готовый фреймворк, использующий GPU, тензоры и всё такое? Я прекрасно понимаю, что GDScript бесполезен для чего-то серьёзного (в машобе)... Но подумайте: в одной колонке мозга всего около 10 тысяч нейронов, и эта колонка выполняет какую-то одну задачу, имея ограниченный "обзор" (входные данные). Мозг крайне медленный (100 Гц), неточный (представьте, какие сложности у отдельных клеток, когда каждый атом на счету) и "плоский" (он в принципе не может быть глубоким из-за низкой скорости и необходимости реагировать как можно скорее; зато колонки выстроены максимально "в ширину") - его преимущество в строении одной колонки, клонированной 2 миллиона раз, чтоб на все случаи жизни хватало, и того, к чему эта колонка прикрепляется...
По идее, сделать примитивный аналог колонки можно на чём угодно, но для этого нужно закопаться в детали реализации отдельных нейронов. И поставить этой колонке какую-то конкретную задачу для решения. Кто её знает, что она в принципе обычно решает (в мозге)? Есть какие-то теории в интернете, но ничего простого и понятного. Типа, по одной из версий каждая колонка - это сам по себе маленький "мозг", решающий задачу навигации в пространстве независимо от соседей за счёт создания своей собственной модели мира... WTF? Как я это должен понимать? Это объяснение ничего не объясняет. Куда понятнее было бы "колонка пытается предсказать будущее" (очевидно, когда до неё доползут актуальные сигналы из внешнего мира, будет уже поздно на них реагировать, поэтому она должна дать правильный "ответ" до получения предсказанного "вопроса") или что-то вроде...
Вот как-то так я пришёл к тому, чтобы ковырять нейроны на GDScript, но приуныл и забил. Снова. И почему меня не удовлетворяет делать простые игры... Ах, да, я ж вкатился в геймдев в основном потому, что мне было скучно с тупыми NPC и я хотел умных, чтоб учились чему-то (на самом деле, обучающиеся в реальном времени NPC существовали в играх ещё в 90-х, представляете?)...
Бонус: как выглядел бы код нейрона, если у него на входе одна 1 и много 0 (one-hot)?
>func neuron(input_id: int, weights: Array[float]) -> float:
>_ return weights[input_id] # нули, очевидно, не нужно ни умножать, ни складывать
А если несколько единиц и остальное по нулям?
>func neuron(input_ids: Array[int], weights: Array[float]) -> float:
>_ var sum: float = 0
>_ for id in input_ids:
>_ _ sum += weights[id] # т.к. у нас только 1 и 0, это просто сумма весов активных входов
>_ return sum # тут можно какую-то функцию активации вставить...
Кажется, у такой модели какое-то название есть. Понятия не имею, какое. Но умножений тут вообще нет, поэтому производительность должна вырасти значительно. А ещё нет лишних операций, потому что отсутствующие сигналы никак не симулируются (это нули). Но, наверное, у такой модели сильно ограниченная сфера применения, поэтому её не используют. На GPU такое считать бессмысленно.
"Winner takes all" выглядит как-то так, если для одного слоя нейронов:
>var max_output: float = -1
>var max_id: int = -1
>for id in neurons.size():
>_ var output := neuron(input, neurons[id])
>_ if output > max_output:
>_ _ max_output = output
>_ _ max_id = id
>return id # самый активный нейрон "выиграл", остальные по нулям
Вообще-то я всё это в классы обернул (RefCounted), но это не важно...
>У меня dev5 и beta1 не запускается в версии x64
Если кого-то ещё это затронуло:
Godot 4.5+ x64 по умолчанию собирается с SSE 4.2 инструкциями.
Мой Xeon E5450 имеет набор инструкций только до SSE 4.1...
Говорят, что пока что можно пересобрать master с только SSE 2:
https://github.com/godotengine/godot/pull/59595
ИМХО, это слишком серьёзное изменение для 4.x релиза...
Что интересно, E5450 и LGA 775 всё ещё на рынке и очень дёшевы.
Алсо, я в бешенстве от слов Calinou:
>pair a ... CPU with a somewhat modern GPU...
>you'd be CPU-limited in every game with that kind of setup
Моя топовая игровая сборка E5450 + 750 Ti тащит 99% игр в 30+ FPS.
И во многих играх я намного чаще "GPU-limited", чем "CPU-limited"...
Даже игры на UE5 умудряются занять 100% GPU, не заполняя CPU.
Ладно. Всё равно планирую собрать новый ПК... через пару лет...
Думаю подождать выхода DDR6, какие подводные? Или DDR5 норм?