1,9 Мб, 1536x1024Добро пожаловать в тред любви, взаимопомощи, и бойлерплейта на шарпах!
Шапка: https://hipolink.me/godothread
Предыдущий: >>1022039 (OP)
Архивный: >>1017767 (OP)
Шапка: https://hipolink.me/godothread
Предыдущий: >>1022039 (OP)
Архивный: >>1017767 (OP)
Первый нах
>>26848
Так создание игры на годоте это и есть лизание писечки годот тян. Представь что ты хочешь ее удовлетворить, часами лижешь и лижешь. Она то возбуждается то опять остывает. Твоя задача раскачать ее писечку до такой чувствительности чтобы довести ее до двухчасового тантрического оргазма. Задача для настоящего симпа годот тян. Но если научится хорошо владеть языком и пальцами, и выучить все ее эрогенные зоны, то однозначно выполнимая задача.
>А она даст мне писечку полизать, если я игру сделаю?
Так создание игры на годоте это и есть лизание писечки годот тян. Представь что ты хочешь ее удовлетворить, часами лижешь и лижешь. Она то возбуждается то опять остывает. Твоя задача раскачать ее писечку до такой чувствительности чтобы довести ее до двухчасового тантрического оргазма. Задача для настоящего симпа годот тян. Но если научится хорошо владеть языком и пальцами, и выучить все ее эрогенные зоны, то однозначно выполнимая задача.
>>1026748 →
Пробовал ещё лет десять назад. Штука отличная, но я всё-таки в сторону геймдева хочу развиваться. А в геймдеве Dear ImGui - практически индустриальный стадарт. И вообще ни одной игры не знаю, которая бы разрабатывалась на диалектах Паскаля.
>Попробуй
Пробовал ещё лет десять назад. Штука отличная, но я всё-таки в сторону геймдева хочу развиваться. А в геймдеве Dear ImGui - практически индустриальный стадарт. И вообще ни одной игры не знаю, которая бы разрабатывалась на диалектах Паскаля.
>>26934
Странно. Я думал создание игр на годоте это скакание на дилдаке из серии Bad Dragon.
>Так создание игры на годоте это и есть лизание писечки годот тян.
Странно. Я думал создание игр на годоте это скакание на дилдаке из серии Bad Dragon.
21 Кб, 283x206ДА БЛЯТЬ! Почему каждый раз после перезахода в двигло слетают блядские цвета альбедо в каждой модельке кроме последней отредаченой?
>>26967
Ресурс один, все сцены ссылаются на него. В последней отредачил - заменил везде. Да и не заменил, а по ссылке в следующий раз откроется отредаченное. Чтобы этого избежать, как тебе показали скрином выше, следует вручную нажать галку, которая сделает ресурс локальным.
Суть ресурсов именно в этом, чтобы они в единственном виде существовали, и по ссылке передавались на единственный экземпляр.
О, кстати, ресурсы - это синглтоны.
Ресурс один, все сцены ссылаются на него. В последней отредачил - заменил везде. Да и не заменил, а по ссылке в следующий раз откроется отредаченное. Чтобы этого избежать, как тебе показали скрином выше, следует вручную нажать галку, которая сделает ресурс локальным.
Суть ресурсов именно в этом, чтобы они в единственном виде существовали, и по ссылке передавались на единственный экземпляр.
О, кстати, ресурсы - это синглтоны.
>>26977
Алсо, еще можно ПКМ по ресурсу (в данном случае материалу) и "make unique". А вообще рекомендую сохранять ресурсы с осмысленными названиями и по возможности переиспользовать их, а не городить свое на каждый объект.
Теперь надо написать доклад на тему почему это плохо.
Алсо, еще можно ПКМ по ресурсу (в данном случае материалу) и "make unique". А вообще рекомендую сохранять ресурсы с осмысленными названиями и по возможности переиспользовать их, а не городить свое на каждый объект.
>О, кстати, ресурсы - это синглтоны.
Теперь надо написать доклад на тему почему это плохо.
>>26957
Возможно, у тебя какой-то не такой воркфлоу, обычно модельки не редактируют в движке, а только импортируют из например блендера.
Возможно, у тебя какой-то не такой воркфлоу, обычно модельки не редактируют в движке, а только импортируют из например блендера.
>>26984
Во-первых это не проблема воркфлоу, это фича движка - передавать ресурсы по ссылке и не дублировать их без явного запроса. Во-вторых делать материалы сразу в движке - полностью норма. У меня например 3д с большим зумом, и простые модельки я могу с помощью CSG наклепать прямо в движке, перегнать в меш, накликать базовый материал и норм - хуй там кто чего разглядит. Запускаю 3д редактор только для чего-то сложного, текстурированного, анимированого.
Во-первых это не проблема воркфлоу, это фича движка - передавать ресурсы по ссылке и не дублировать их без явного запроса. Во-вторых делать материалы сразу в движке - полностью норма. У меня например 3д с большим зумом, и простые модельки я могу с помощью CSG наклепать прямо в движке, перегнать в меш, накликать базовый материал и норм - хуй там кто чего разглядит. Запускаю 3д редактор только для чего-то сложного, текстурированного, анимированого.
>>26988
Просто мой глаз зацепился за то, с чем давно не сталкивался, поэтому подозреваю там какую то ловушку новчика, типа дублировать всю сцену персонажа и в результате иметь 5 вариантов одного и того же персонажа с разным альбедо, вместо просто замены материала.
Просто мой глаз зацепился за то, с чем давно не сталкивался, поэтому подозреваю там какую то ловушку новчика, типа дублировать всю сцену персонажа и в результате иметь 5 вариантов одного и того же персонажа с разным альбедо, вместо просто замены материала.
1,1 Мб, 480x380>>26834 (OP)
Ну чё, имба или не?
https://www.reddit.com/r/godot/comments/1lg0t11/this_is_ndb_indiehorror_game/
А то жаловались дескать игр-то нет.
Ну чё, имба или не?
https://www.reddit.com/r/godot/comments/1lg0t11/this_is_ndb_indiehorror_game/
А то жаловались дескать игр-то нет.
>>27018
Я бы поиграл в эту шизу, когда релиз?
Я бы поиграл в эту шизу, когда релиз?
>>27018
Полистал собстна этот редит по годоте. И чет ахуел. Чому там все засрану вылизаными 2д играми то? Разве наш годот не движок для шизофреников?
Полистал собстна этот редит по годоте. И чет ахуел. Чому там все засрану вылизаными 2д играми то? Разве наш годот не движок для шизофреников?
>>27046
Тред для шизофреников там ->
Тред для шизофреников там ->
>>26990
Не, анончик, я не настолько прям новичок, чтобы о такие вещи спотыкаться. У меня есть оригинальная сцена нескольких айтемов, они у игрока есть по умолчанию и потому подгружаются сразу после перехода с главного меню и больше никуда не деваются и не дублируются. Я албеду накинул просто потому-что у меня модельки из блендера а колор-рамп из него почему-то не экспортируется в .glb (во всяком случае у меня). (а запекать текстуры и всю эту хуйню я не умею) Потому я подкручиваю цвет альбедой. Уже в привычку вошло. Так вот, прикол даже не в самой игре, как таковой. Я могу в сцене покрутить цвет, сохранить сцену (материал не сохранен в файл) и перезайти в движок. После этого альбедо опять сбрасывается везде, кроме последнего редактированного меша. То есть выглядит эта ситуация, будто баг в самом редакторе.
Не, анончик, я не настолько прям новичок, чтобы о такие вещи спотыкаться. У меня есть оригинальная сцена нескольких айтемов, они у игрока есть по умолчанию и потому подгружаются сразу после перехода с главного меню и больше никуда не деваются и не дублируются. Я албеду накинул просто потому-что у меня модельки из блендера а колор-рамп из него почему-то не экспортируется в .glb (во всяком случае у меня). (а запекать текстуры и всю эту хуйню я не умею) Потому я подкручиваю цвет альбедой. Уже в привычку вошло. Так вот, прикол даже не в самой игре, как таковой. Я могу в сцене покрутить цвет, сохранить сцену (материал не сохранен в файл) и перезайти в движок. После этого альбедо опять сбрасывается везде, кроме последнего редактированного меша. То есть выглядит эта ситуация, будто баг в самом редакторе.
Когда в Годот завезут?
https://www.youtube.com/watch?v=bwJgifqvd5M
> Vertex Block Descent — это быстрый метод моделирования на основе физики, который безусловно стабилен, хорошо поддается параллелизации и способен сходиться к неявному решению Эйлера. Мы расширяем его с помощью расширенной лагранжевой формулировки, чтобы устранить некоторые из его фундаментальных ограничений. Во-первых, мы вводим механизм для обработки жестких ограничений с бесконечной жесткостью без введения числовых нестабильностей. Во-вторых, мы существенно улучшаем сходимость при наличии высоких коэффициентов жесткости. Эти изменения, которые мы вводим, позволяют моделировать сложные контактные сценарии, включающие жесткие тела с укладкой и трением, сочлененные тела, соединенные жесткими ограничениями, включая суставы с ограниченными степенями свободы, и жесткие системы, взаимодействующие с мягкими телами. Мы представляем оценки с использованием параллельной реализации на GPU, которая может обеспечить производительность в реальном времени и стабильное моделирование с низким числом итераций для миллионов объектов, взаимодействующих посредством столкновений, различных ограничений суставов/креплений и пружин различной жесткости. Наши результаты показывают превосходную производительность, сходимость и устойчивость по сравнению с современными альтернативами.
https://www.youtube.com/watch?v=bwJgifqvd5M
Означает ли это что теперь получится делать stencil shadows, как у дедов?
>>27078
ВЕЧЕРОМ ДЕНЬГИ - УТРОМ КОД! ИЛИ НАОБОРОТ - УТРОМ ДЕНЬГИ - ВЕЧЕРОМ КОД!
ВЕЧЕРОМ ДЕНЬГИ - УТРОМ КОД! ИЛИ НАОБОРОТ - УТРОМ ДЕНЬГИ - ВЕЧЕРОМ КОД!
>>26979
Ну так а вдруг ты внезапно захочешь мультиплеер?
>>27067
Если бы можно сделать шрифт ещё мельче, ты бы сделал, да?
>>27065
Попробуй отконвертировать материал в шейдер. Ну так, мало ли.
Можно ещё попробовать в исходниках годота сделать grep albedo, но я вангую, что там ничего специфического не найдёшь. Скорее всего, проблема где-то в файлах сцен. Странно было бы, если бы к одному ресурсу было особенное отношение в исходниках.
>Теперь надо написать доклад на тему почему это плохо.
Ну так а вдруг ты внезапно захочешь мультиплеер?
>>27067
Если бы можно сделать шрифт ещё мельче, ты бы сделал, да?
>>27065
Попробуй отконвертировать материал в шейдер. Ну так, мало ли.
Можно ещё попробовать в исходниках годота сделать grep albedo, но я вангую, что там ничего специфического не найдёшь. Скорее всего, проблема где-то в файлах сцен. Странно было бы, если бы к одному ресурсу было особенное отношение в исходниках.
96 Кб, 1080x667>>27067
Дау угадаю, основан на поиске чисельной производной и добавлением получившегося вектора вниз с теми же проблемами.
>Descent
Дау угадаю, основан на поиске чисельной производной и добавлением получившегося вектора вниз с теми же проблемами.
>>26938
Странно, обычно же используют 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.
ОП, извини, что не совсем по теме.
>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.
ОП, извини, что не совсем по теме.
>>27104
В где угодно - да. А в игровой индустрии - https://github.com/ocornut/imgui/wiki/Software-using-dear-imgui
Тот же QT претендует на главный цикл приложения, насчёт GTK не знаю, но вроде тоже. А в главном цикле у всех нормальных игровых движков вообще-то движок. Плюс эту штуковину можно прямо в проект добавить, у неё зависимостей ноль ну, кроме графических фреймворков; ну так их движок за собой тащит в любом случае.
Во-первых, easy cum easy go.
Во-вторых, проприетарные движки умирают точно так же, просто это отследить сложнее.
В-третьих, то была эпоха, когда у каждой дворовой собаки был свой игровой движок. А сейчас написать свой движок становится всё сложнее и сложнее, особенно если хочется современных технологий и вылкана, зато готовеньких полно на любой вкус.
А вообще, шо тебе дался этот паскаль? Я понимаю, что игры на чём угодно пишут, хоть на редстоуне. Но так-то в целом паскаль не для этого.
А вообще, благородный дон, если желаете продолжить беседу, предлагаю перейти в отдельный тред.
>Странно, обычно же используют Qt или GTK+?
В где угодно - да. А в игровой индустрии - https://github.com/ocornut/imgui/wiki/Software-using-dear-imgui
Тот же QT претендует на главный цикл приложения, насчёт GTK не знаю, но вроде тоже. А в главном цикле у всех нормальных игровых движков вообще-то движок. Плюс эту штуковину можно прямо в проект добавить, у неё зависимостей ноль ну, кроме графических фреймворков; ну так их движок за собой тащит в любом случае.
>Печально, что опенсурс движки так часто умирают.
Во-первых, easy cum easy go.
Во-вторых, проприетарные движки умирают точно так же, просто это отследить сложнее.
В-третьих, то была эпоха, когда у каждой дворовой собаки был свой игровой движок. А сейчас написать свой движок становится всё сложнее и сложнее, особенно если хочется современных технологий и вылкана, зато готовеньких полно на любой вкус.
А вообще, шо тебе дался этот паскаль? Я понимаю, что игры на чём угодно пишут, хоть на редстоуне. Но так-то в целом паскаль не для этого.
А вообще, благородный дон, если желаете продолжить беседу, предлагаю перейти в отдельный тред.
>>27129
Так я сижу на Godot >5 лет уже...
Синдром утёнка.
Если серьёзно, потомки Pascal занимают интересную промежуточную нишу, аналогов которой я не нашёл. Потенциально полезно в контексте Godot:
- моментальная компиляция, в отличие от долго собирающегося C/C++/C# и их разновидностей;
- относительно высокая производительность, т.е. приблизительно на уровне C#, чуть похуже C++ (т.к. оптимизировать код в один проход очень сложно);
- отсутствует GC - лучше подходит для игр, чем C#;
- читабельность кода выше, поскольку вместо спецсимволов и сокращений - полные слова;
- нативный код без виртуальной машины, т.е. можно линковать с кодом на C/C++, т.е. в теории возможно написать свой Godot-модуль на Pascal, а не просто прилепить снаружи через GDNative/GDExtension;
- относительно популярен, в отличие от уже совсем забытых языков и совсем недавно придуманных.
Вкратце, это альтернатива C++, но без критических недостатков C#, Rust и прочих "как C, но не C". Все недостатки сводятся к "дольше печатать", но кого это волнует в эпоху генерации кода нейронками, лол. А читать-то лучше длинные слова, чем {крякозябры()::}, восприятие мозга лучше всего работает со словами.
>перейти в отдельный тред
Так я сижу на Godot >5 лет уже...
>шо тебе дался этот паскаль?
Синдром утёнка.
Если серьёзно, потомки Pascal занимают интересную промежуточную нишу, аналогов которой я не нашёл. Потенциально полезно в контексте Godot:
- моментальная компиляция, в отличие от долго собирающегося C/C++/C# и их разновидностей;
- относительно высокая производительность, т.е. приблизительно на уровне C#, чуть похуже C++ (т.к. оптимизировать код в один проход очень сложно);
- отсутствует GC - лучше подходит для игр, чем C#;
- читабельность кода выше, поскольку вместо спецсимволов и сокращений - полные слова;
- нативный код без виртуальной машины, т.е. можно линковать с кодом на C/C++, т.е. в теории возможно написать свой Godot-модуль на Pascal, а не просто прилепить снаружи через GDNative/GDExtension;
- относительно популярен, в отличие от уже совсем забытых языков и совсем недавно придуманных.
Вкратце, это альтернатива C++, но без критических недостатков C#, Rust и прочих "как C, но не C". Все недостатки сводятся к "дольше печатать", но кого это волнует в эпоху генерации кода нейронками, лол. А читать-то лучше длинные слова, чем {крякозябры()::}, восприятие мозга лучше всего работает со словами.
>>26977
Кто тебе это сказал? Синглтон - это класс, у которого:
- может существовать только один экземпляр;
- доступ глобально по уникальному имени.
А что у Resource?
- можно создать любое количество экземпляров;
- нет глобального доступа по имени, т.е. локальны.
Сцены используют общие ресурсы, но это не имеет абсолютно никакой связи с паттерном "синглтон". Использование общих ресурсов - это просто ссылки (указатели, pointer) на конкретный экземпляр класса.
>>26984
Материалы обычно в движке редактируются, т.к. у Блендера свой собственный рендерер, он не точно соответствует рендереру Godot, плюс шейдеры ты можешь писать только на языке Godot.
>>26988
CSG часто делает тонкие и вытянутые треугольники. Разницу на ПК вряд ли заметишь, но на мобильных устройствах это критический недостаток CSG мешей.
>>27065
Как ты используешь импортированные glb?
1. Создаёшь новую сцену-потомка glb и сохраняешь отдельно в виде сцены tscn?
2. Добавляешь glb сцену в сцену tscn и выбираешь редактирование вложенных нод?
Я лично сталкивался с проблемами сцен-потомков неоднократно, особенно когда импортирую новую модельку вместо старой. Поэтому использую второй метод, он кажется более надёжным (но не всегда).
Также рекомендую сохранить все свои материалы в отдельные tres файлы и соединять их к моделям по необходимости, а не редактировать внутри моделей. Потому что так меньше риск потерять настройки.
Аналогично с любыми другими ресурсами, у которых имеется много полей или много данных в одном поле.
>ресурсы - это синглтоны
Кто тебе это сказал? Синглтон - это класс, у которого:
- может существовать только один экземпляр;
- доступ глобально по уникальному имени.
А что у Resource?
- можно создать любое количество экземпляров;
- нет глобального доступа по имени, т.е. локальны.
Сцены используют общие ресурсы, но это не имеет абсолютно никакой связи с паттерном "синглтон". Использование общих ресурсов - это просто ссылки (указатели, pointer) на конкретный экземпляр класса.
>>26984
>модельки не редактируют в движке
Материалы обычно в движке редактируются, т.к. у Блендера свой собственный рендерер, он не точно соответствует рендереру Godot, плюс шейдеры ты можешь писать только на языке Godot.
>>26988
>3д с большим зумом
>CSG наклепать прямо в движке
CSG часто делает тонкие и вытянутые треугольники. Разницу на ПК вряд ли заметишь, но на мобильных устройствах это критический недостаток CSG мешей.
>>27065
Как ты используешь импортированные glb?
1. Создаёшь новую сцену-потомка glb и сохраняешь отдельно в виде сцены tscn?
2. Добавляешь glb сцену в сцену tscn и выбираешь редактирование вложенных нод?
Я лично сталкивался с проблемами сцен-потомков неоднократно, особенно когда импортирую новую модельку вместо старой. Поэтому использую второй метод, он кажется более надёжным (но не всегда).
Также рекомендую сохранить все свои материалы в отдельные tres файлы и соединять их к моделям по необходимости, а не редактировать внутри моделей. Потому что так меньше риск потерять настройки.
Аналогично с любыми другими ресурсами, у которых имеется много полей или много данных в одном поле.
>>26977
Кто тебе это сказал? Синглтон - это класс, у которого:
- может существовать только один экземпляр;
- доступ глобально по уникальному имени.
А что у Resource?
- можно создать любое количество экземпляров;
- нет глобального доступа по имени, т.е. локальны.
Сцены используют общие ресурсы, но это не имеет абсолютно никакой связи с паттерном "синглтон". Использование общих ресурсов - это просто ссылки (указатели, pointer) на конкретный экземпляр класса.
>>26984
Материалы обычно в движке редактируются, т.к. у Блендера свой собственный рендерер, он не точно соответствует рендереру Godot, плюс шейдеры ты можешь писать только на языке Godot.
>>26988
CSG часто делает тонкие и вытянутые треугольники. Разницу на ПК вряд ли заметишь, но на мобильных устройствах это критический недостаток CSG мешей.
>>27065
Как ты используешь импортированные glb?
1. Создаёшь новую сцену-потомка glb и сохраняешь отдельно в виде сцены tscn?
2. Добавляешь glb сцену в сцену tscn и выбираешь редактирование вложенных нод?
Я лично сталкивался с проблемами сцен-потомков неоднократно, особенно когда импортирую новую модельку вместо старой. Поэтому использую второй метод, он кажется более надёжным (но не всегда).
Также рекомендую сохранить все свои материалы в отдельные tres файлы и соединять их к моделям по необходимости, а не редактировать внутри моделей. Потому что так меньше риск потерять настройки.
Аналогично с любыми другими ресурсами, у которых имеется много полей или много данных в одном поле.
>ресурсы - это синглтоны
Кто тебе это сказал? Синглтон - это класс, у которого:
- может существовать только один экземпляр;
- доступ глобально по уникальному имени.
А что у Resource?
- можно создать любое количество экземпляров;
- нет глобального доступа по имени, т.е. локальны.
Сцены используют общие ресурсы, но это не имеет абсолютно никакой связи с паттерном "синглтон". Использование общих ресурсов - это просто ссылки (указатели, pointer) на конкретный экземпляр класса.
>>26984
>модельки не редактируют в движке
Материалы обычно в движке редактируются, т.к. у Блендера свой собственный рендерер, он не точно соответствует рендереру Godot, плюс шейдеры ты можешь писать только на языке Godot.
>>26988
>3д с большим зумом
>CSG наклепать прямо в движке
CSG часто делает тонкие и вытянутые треугольники. Разницу на ПК вряд ли заметишь, но на мобильных устройствах это критический недостаток CSG мешей.
>>27065
Как ты используешь импортированные glb?
1. Создаёшь новую сцену-потомка glb и сохраняешь отдельно в виде сцены tscn?
2. Добавляешь glb сцену в сцену tscn и выбираешь редактирование вложенных нод?
Я лично сталкивался с проблемами сцен-потомков неоднократно, особенно когда импортирую новую модельку вместо старой. Поэтому использую второй метод, он кажется более надёжным (но не всегда).
Также рекомендую сохранить все свои материалы в отдельные tres файлы и соединять их к моделям по необходимости, а не редактировать внутри моделей. Потому что так меньше риск потерять настройки.
Аналогично с любыми другими ресурсами, у которых имеется много полей или много данных в одном поле.
>>27067
Берёшь код (тянучка писала?!):
https://github.com/AnkaChan/Gaia
Добавляешь в движок по гайду:
https://docs.godotengine.org/en/stable/contributing/development/core_and_modules/custom_modules_in_cpp.html
Только зачем? Тебе мягкие тела в игре нужны?
Берёшь код (тянучка писала?!):
https://github.com/AnkaChan/Gaia
Добавляешь в движок по гайду:
https://docs.godotengine.org/en/stable/contributing/development/core_and_modules/custom_modules_in_cpp.html
Только зачем? Тебе мягкие тела в игре нужны?
Как можно найти используется ли где-нибудь в проекте конкретный слой коллизий? Поясню проблему. Я поставил одному из физических слоев имя, и не уверен что использовал его хоть раз. Но удалять/переиспользовать его стремно, вдруг он все же используется, а я забыл где. Пока перебираю вручную.
>>27207
Придумал крч огромную area на весь уровень, и так на каждом уровне, и этой ареа выставил только подозрительный слой. Ничего не нашлось. Видимо не использовал.
Придумал крч огромную area на весь уровень, и так на каждом уровне, и этой ареа выставил только подозрительный слой. Ничего не нашлось. Видимо не использовал.
>>27207
Напиши какой нибудь тул скрипт или просто скрипт. Который рекурсивно обходит все ноды. Что нибудь по типу 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("бабах")
Напиши какой нибудь тул скрипт или просто скрипт. Который рекурсивно обходит все ноды. Что нибудь по типу 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("бабах")
>>27220
Тоже норм решение, спасибо.
Тоже норм решение, спасибо.
>>27243
Да, если отказаться от физики жидкостей и частиц заменив ее другими штуками попроще, например разрушаемость как в червяках сделать, но раз ты спрашиваешь то ты не осилишь
Да, если отказаться от физики жидкостей и частиц заменив ее другими штуками попроще, например разрушаемость как в червяках сделать, но раз ты спрашиваешь то ты не осилишь
Я правильно понимаю, что за 4 года разраб не осилил создание списка в 1 строчку?
github.com/godotengine/godot-proposals/issues/2972
Ебанный позор
github.com/godotengine/godot-proposals/issues/2972
Ебанный позор
В качестве практики сел делать клон гвинта, понял что тону в проектировании структуры проекта. Вот допустим при наведении на карту она должна выделяться. Сделать для этого функцию в скрипте карты? Но тогда она будет срабатывать каждый раз без оглядки на окружающую ситуацию. Запихнуть код в корень сцены? Тогда придётся тянуть от карт сигналы через всё дерево сцены.
По итогу полное ощущение что получается говнокод, который тяжело читать, легко сломать и невозможно масштабировать. Каких материалов анонимус советует покурить, чтобы набраться скилла в этом направлении?
По итогу полное ощущение что получается говнокод, который тяжело читать, легко сломать и невозможно масштабировать. Каких материалов анонимус советует покурить, чтобы набраться скилла в этом направлении?
>>27253
А в чем проблема физики жидкостей в годоте?
Мимо
>Да, если отказаться от физики жидкостей и частиц заменив ее другими штуками попроще
А в чем проблема физики жидкостей в годоте?
Мимо
И да писать все придется на плюсах.
Можно как вариант на расте.
Жаль раст пока что почти не юзают в игровой разработке.
Можно как вариант на расте.
Жаль раст пока что почти не юзают в игровой разработке.
>>27301
Есть бинды раста в годот. Делай.
Есть бинды раста в годот. Делай.
>>27243
Да, готовся забыть про ноды и само существование такого понятия как нода для игровых объектов. PhysicServer для тебя не существует и заменяется на Dummy, отныне RenderingService - всё что для тебя существует. Про c# забывай, и пути у тебя два - либо писать всю игру на gdextension (то есть на плюсах) либо на gds. Соответственно только годот4, гд3 отпадает. gdextension тебе всё равно потребуется чтобы писать максимально облегченную физику. Если совсем коротко - придется практически всё кроме системы ресурсов и интерфейса делать за движок вплоть до его непосредственного редактирования (движка). У этого будут и свои плюсы, типа того что если ты удачно встроишься в движок - получишь все его блага (мультиплатформа, готовый язык шейдеров и в частности compute шейдеров) - но придется прям непосредственно знакомиться с темной стороной годота. Сумеешь - выиграешь большой объем бонусов. Не сумеешь - будет неприятно и проебано много времени.
Да, готовся забыть про ноды и само существование такого понятия как нода для игровых объектов. PhysicServer для тебя не существует и заменяется на Dummy, отныне RenderingService - всё что для тебя существует. Про c# забывай, и пути у тебя два - либо писать всю игру на gdextension (то есть на плюсах) либо на gds. Соответственно только годот4, гд3 отпадает. gdextension тебе всё равно потребуется чтобы писать максимально облегченную физику. Если совсем коротко - придется практически всё кроме системы ресурсов и интерфейса делать за движок вплоть до его непосредственного редактирования (движка). У этого будут и свои плюсы, типа того что если ты удачно встроишься в движок - получишь все его блага (мультиплатформа, готовый язык шейдеров и в частности compute шейдеров) - но придется прям непосредственно знакомиться с темной стороной годота. Сумеешь - выиграешь большой объем бонусов. Не сумеешь - будет неприятно и проебано много времени.
>>27299
Она требует определённой оптимизации, которую gdscript не даст, да даже голый C++ без определённых знаний не даст с нормальным FPS эмулировать столько частиц
Она требует определённой оптимизации, которую gdscript не даст, да даже голый C++ без определённых знаний не даст с нормальным FPS эмулировать столько частиц
Бля, сделал игру на геймджем, а она в ленте проектов не появляется, хотя вторая игра на аккаунте. Аноны, поддержка итча быстро помогает?
>>27324
Ну я же не ньюфаг, всё сделано, как всегда, а игры в ленте и поиске сайта нету
Ну я же не ньюфаг, всё сделано, как всегда, а игры в ленте и поиске сайта нету
>>27318
С чего бы?
А почему нельзя написать игру на gdextension (то есть на плюсах) которая будет представлена единственной нодой, которую он затем выложит на стартовую сцену и к ней добавит гуй на зелёных нодах?
> готовся забыть про ноды
С чего бы?
А почему нельзя написать игру на gdextension (то есть на плюсах) которая будет представлена единственной нодой, которую он затем выложит на стартовую сцену и к ней добавит гуй на зелёных нодах?
>>27326
Мне обязательно надо обьяснять почему это не будет игровой сценой базирующейся на нодах?
Мне обязательно надо обьяснять почему это не будет игровой сценой базирующейся на нодах?
>>27328
Если бы я сказал только о физике частиц, это могло быть не понятно, можно дальше не доёбываться, отдельная обработка частиц жидкости в ней есть
Если бы я сказал только о физике частиц, это могло быть не понятно, можно дальше не доёбываться, отдельная обработка частиц жидкости в ней есть
>>27322
Я читал что это обычное дело, она может попасть в очередь на ручную модерацию, и вообще официальный ответ итча у нас выходят тысячи игр, не рассчитывайте на ленту, раскручивайтесь сами.
Я читал что это обычное дело, она может попасть в очередь на ручную модерацию, и вообще официальный ответ итча у нас выходят тысячи игр, не рассчитывайте на ленту, раскручивайтесь сами.
207 Кб, 1168x770>>27329
Это симулятор сыпучих пикселей, к которому добавили пару правил для покачивания волн, но не добавили рассчет давления или векторы течения.
Вывод - если в нойте отказались от симуляции жидкости, то и в твоей игре на годоте ты можешь спокойно отказаться. Можешь начинать делать игру на годоте.
В гд3 есть GDNative, а так же модули движка, поэтому проблемы писать на c++ нет. Вот для чего может быть смысл брать гд4, это компьют шейдеры. Но на них написать такую игру может оказаться сложно, потому что она плохо параллелиться (вычисления зависят от соседних пикселей, а для распараллеливания лучше независимые).
Это симулятор сыпучих пикселей, к которому добавили пару правил для покачивания волн, но не добавили рассчет давления или векторы течения.
Вывод - если в нойте отказались от симуляции жидкости, то и в твоей игре на годоте ты можешь спокойно отказаться. Можешь начинать делать игру на годоте.
>Соответственно только годот4, гд3 отпадает.
В гд3 есть GDNative, а так же модули движка, поэтому проблемы писать на c++ нет. Вот для чего может быть смысл брать гд4, это компьют шейдеры. Но на них написать такую игру может оказаться сложно, потому что она плохо параллелиться (вычисления зависят от соседних пикселей, а для распараллеливания лучше независимые).
>>27333
P.s. это нужно для сообщающихся сосудов (communicating vessels), которые в нойте не симулируются.
> рассчет давления
P.s. это нужно для сообщающихся сосудов (communicating vessels), которые в нойте не симулируются.
>>27301
Bevy вполне себе взлетел. Регулярно вижу про него посты в своей ленте, и про игры на нем. Вот эта охуительная штука на Беви/Расте, посмотри как там билдится на лету: https://store.steampowered.com/app/2198150/Tiny_Glade/
Вот что не взлетело для геймдева, так это Го. Было полтора движка от васянов, один из них умер, другой чисто 2д. Хотя как язык норм, живой-популярный.
>Жаль раст пока что почти не юзают в игровой разработке.
Bevy вполне себе взлетел. Регулярно вижу про него посты в своей ленте, и про игры на нем. Вот эта охуительная штука на Беви/Расте, посмотри как там билдится на лету: https://store.steampowered.com/app/2198150/Tiny_Glade/
Вот что не взлетело для геймдева, так это Го. Было полтора движка от васянов, один из них умер, другой чисто 2д. Хотя как язык норм, живой-популярный.
>>27347
Я кстати до вката в геймдев думал что Godot это движок на Go, лул.
Я кстати до вката в геймдев думал что Godot это движок на Go, лул.
>>27347
Не "взлетел", а там тянка натужно форсила себя в твиттере. Геймплей то туда так и не завезли.
Не "взлетел", а там тянка натужно форсила себя в твиттере. Геймплей то туда так и не завезли.
>>27333
Если переходить на тройку (кстати - зачем? Непременно нужно легаси? И лагающий 2 опенгл?) - то от гдс придется отказаться впринципе и делать игру на плюсах полностью, хотя я бы например логику и управление нпс писал бы на гдс, так попроще и гдс в 4 годоте нормально прикручен к движку, а в с++ выносил только реально тяжеловесное. Можно конечно вообще всё на с++, но можно и не всё. Компьют шейдеры помогут считать физику жидкости, так что их бы тоже оставить. Гднатив это вообще другого поля ягода, использовать его для подключения плюсов это всё равно что ковыряться в двигателе через выхлопную трубу, потому как оверхед у него смертельный для производительности, так что только c++ модули либо прямое редактирование движка, что по сути своей одно и то же, так как придется ребилдить движок раз за разом. Почему гднатив говно можно узнать тут https://sampruden.github.io/posts/godot-is-not-the-new-unity/ и с момента публикации статьи ситуация лучше не стала.
Если переходить на тройку (кстати - зачем? Непременно нужно легаси? И лагающий 2 опенгл?) - то от гдс придется отказаться впринципе и делать игру на плюсах полностью, хотя я бы например логику и управление нпс писал бы на гдс, так попроще и гдс в 4 годоте нормально прикручен к движку, а в с++ выносил только реально тяжеловесное. Можно конечно вообще всё на с++, но можно и не всё. Компьют шейдеры помогут считать физику жидкости, так что их бы тоже оставить. Гднатив это вообще другого поля ягода, использовать его для подключения плюсов это всё равно что ковыряться в двигателе через выхлопную трубу, потому как оверхед у него смертельный для производительности, так что только c++ модули либо прямое редактирование движка, что по сути своей одно и то же, так как придется ребилдить движок раз за разом. Почему гднатив говно можно узнать тут https://sampruden.github.io/posts/godot-is-not-the-new-unity/ и с момента публикации статьи ситуация лучше не стала.
>>27380
Там нюфаг не разобрался и потом бегал с извенениями, что все напутал.
Там нюфаг не разобрался и потом бегал с извенениями, что все напутал.
>>27380
Между GDNative и модулями с точки зрения программирования нет практически никакой разницы, поэтому разрабатываешь быстрыми итерациями используя GDNative и перекомпилируя только свою легковесную длл, а когда дело будет к релизу, пересобираешь уже как модуль, делать это надо будет редко.
Про оверхед, звучит голословно, продемонстрируй бенчмарки.
Между GDNative и модулями с точки зрения программирования нет практически никакой разницы, поэтому разрабатываешь быстрыми итерациями используя GDNative и перекомпилируя только свою легковесную длл, а когда дело будет к релизу, пересобираешь уже как модуль, делать это надо будет редко.
Про оверхед, звучит голословно, продемонстрируй бенчмарки.
>>27386
Не разрабатывал, не знаю, но это звучит бредово, потому что гднатив это апи к движку, которое имеет собственный оверхед на то чтобы преобразовывать внутренние типы в то что можно отдать по апи и лучшей иллюстрацией тому является данная мной ссылка выше, где в секции рейкаста результат упаковывается не в структуру, не в обьект, а в словарь в куче из variant с ключами в виде строк. Насколько я помню гднатив не позволяет вызывать методы движка, не вынесенные в заголовочные файлы под гднатив, а значит нужно будет каждый такой "тяжелый" вызов засовывать в макросы с вариантом для игры как модуля и для игры как гднатив.
>Между GDNative и модулями с точки зрения программирования нет практически никакой разницы
Не разрабатывал, не знаю, но это звучит бредово, потому что гднатив это апи к движку, которое имеет собственный оверхед на то чтобы преобразовывать внутренние типы в то что можно отдать по апи и лучшей иллюстрацией тому является данная мной ссылка выше, где в секции рейкаста результат упаковывается не в структуру, не в обьект, а в словарь в куче из variant с ключами в виде строк. Насколько я помню гднатив не позволяет вызывать методы движка, не вынесенные в заголовочные файлы под гднатив, а значит нужно будет каждый такой "тяжелый" вызов засовывать в макросы с вариантом для игры как модуля и для игры как гднатив.
>>27387
Да, собрали свой суповой набор, в том числе и из кусков беви, но это не то же самое что просто взять беви, там сдф реймаршинг, поэтому важна тут первая строчка в первую очередь, о рендере, в терминах годот ближайшей аналогией будет использование огромного компут шейдера который будет делать 99% работы. Ну, а если ты в состоянии собрать свой движок из кусков существующих, то смысла гоняться за растом/беви - нет, в смысле они не облегчают сильно работу, просто инструмент.
Да, собрали свой суповой набор, в том числе и из кусков беви, но это не то же самое что просто взять беви, там сдф реймаршинг, поэтому важна тут первая строчка в первую очередь, о рендере, в терминах годот ближайшей аналогией будет использование огромного компут шейдера который будет делать 99% работы. Ну, а если ты в состоянии собрать свой движок из кусков существующих, то смысла гоняться за растом/беви - нет, в смысле они не облегчают сильно работу, просто инструмент.
>>27390
Пример по твоей ссылке показывают работу с GDNative на C, если откроешь пример на C для GDExtention там будет такой же пезденящий дущу леденец
>где в секции рейкаста результат упаковывается не в структуру, не в обьект, а в словарь в куче из variant с ключами в виде строк
Пример по твоей ссылке показывают работу с GDNative на C, если откроешь пример на C для GDExtention там будет такой же пезденящий дущу леденец
>>27391
Ладно.
Ладно.
129 Кб, 857x632Внимание внимание, несу инсайд про ассет стор.
https://store-beta.godotengine.org
Правда открывается у меня только через впню
https://store-beta.godotengine.org
Правда открывается у меня только через впню
Господа, годачеры, всем доброго времени суток.
Как мне принудительно вызвать _get_drag_data?
В том плане, что у меня есть инвентарь со слотами. У каждого слота есть _get_drag_data, которая автоматом отслеживает нажатие и начинает перетаскивание предметов.
Но как его вызвать принудительно? Вот допустим я у слота вызываю контекстное меню и там кнопка "разделить", после нажатия на которую у меня должно сразу срабатывать перетаскивание.
Или легче будет вообще забить на строенные функции и просто самому запилить систему менеджмента инвентаря с чем-то вроде slot_rect.has_point(mouse_position)?
Ощущение, что для гибкой настройки _get_drag_data не очень то подходит либо я криворукий
Как мне принудительно вызвать _get_drag_data?
В том плане, что у меня есть инвентарь со слотами. У каждого слота есть _get_drag_data, которая автоматом отслеживает нажатие и начинает перетаскивание предметов.
Но как его вызвать принудительно? Вот допустим я у слота вызываю контекстное меню и там кнопка "разделить", после нажатия на которую у меня должно сразу срабатывать перетаскивание.
Или легче будет вообще забить на строенные функции и просто самому запилить систему менеджмента инвентаря с чем-то вроде slot_rect.has_point(mouse_position)?
Ощущение, что для гибкой настройки _get_drag_data не очень то подходит либо я криворукий
>>27444
Да-да, уже готовлюсь продавать эту вашу Хоппу.
Нормально все. Учитывая что почти все плагины к годоту опенсорсные это по сути способ удобно задонатить разработчикам плагинов. Ну и удобно скачать/найти нужное.
Да-да, уже готовлюсь продавать эту вашу Хоппу.
Нормально все. Учитывая что почти все плагины к годоту опенсорсные это по сути способ удобно задонатить разработчикам плагинов. Ну и удобно скачать/найти нужное.
>>27441
Я хз братан.
Я хз братан.
>>27444
Ты же ныл до этого что плохо когда нет профессиональных ассетов решающих сложные задачи. Переобулся?
Ты же ныл до этого что плохо когда нет профессиональных ассетов решающих сложные задачи. Переобулся?
>>27441
Там упомянута функция force_drag, она вроде принудительно заставляет объект таскаться даже если на него не кликнули.
Там упомянута функция force_drag, она вроде принудительно заставляет объект таскаться даже если на него не кликнули.
>>27493
Даже не знаю, с чего ты решил, что это был я. Какая-то попытка на ярость?!
Даже не знаю, с чего ты решил, что это был я. Какая-то попытка на ярость?!
>imgui
>нельзя даже сделать интерфейс который скейлится от размера окна без написания костылей
Хехмда
>>27565
То что ты считаешь костылями, настоящие кодеры считают свободой самовыражения. Они могут так написать, а могут эдак написать. И в целом они могут написать, а ты не можешь. Ты можешь только у чат-бота запрашивать код, получать портянку, не глядя компилировать, а потом жаловаться на костыли. Что не так? Не так? А?
То что ты считаешь костылями, настоящие кодеры считают свободой самовыражения. Они могут так написать, а могут эдак написать. И в целом они могут написать, а ты не можешь. Ты можешь только у чат-бота запрашивать код, получать портянку, не глядя компилировать, а потом жаловаться на костыли. Что не так? Не так? А?
90 Кб, 960x960Котаны, есть что готовое по теме на годоте?
Короч, надо кубики в 3D и чтобы их таскать мона было мышкой и настраивать кубики, и чтобы не запариваться с нуля - долго и сложно.
Короч, надо кубики в 3D и чтобы их таскать мона было мышкой и настраивать кубики, и чтобы не запариваться с нуля - долго и сложно.
>>27594
Показывай скрин редактора, что уже сделано.
Показывай скрин редактора, что уже сделано.
>>27588
А что там делать то? Хуяк хуяк и кубы шеволятся.
А что там делать то? Хуяк хуяк и кубы шеволятся.
531 Кб, 1180x1196>>27594
Ну ладно, хелпаю. Это называется дайс, и оно есть реализованное. Пикрелейтед. Дальше сам.
Ну ладно, хелпаю. Это называется дайс, и оно есть реализованное. Пикрелейтед. Дальше сам.
>>27286
Анонимус, помни - сигналы - это просто заплатка прикрывающая дерьмовую архитектуру. Они очень просты, выглядят легко, казалось бы - надо чтобы одна ветка программы заставила другую её ветку сделать что-то, что другая ветка сама по себе бы и не собиралась делать. Но в этот момент ты на ровном месте формируешь сайд-эффект, который неформально в рантайме связывает то, что связанным быть никак не должно, это даже хуже чем синглтон, его зависимости хотябы отслеживаемы.
У карт есть обладатель, у обладателя есть level/session controller, у level/session controller есть gamecontainer в рамках которого игровая сессия имеет уникальный ид. Взаимодействие карт происходит через статический код, куда передается набор обладателей карт, взаимодействующих в данный момент, над ними производятся вычисления, вызываются методы обновления переданных в этот статический код обьектов и так происходит игровой процесс взаимодействия карт. Если карта сама по себе пожелает что-то сделать (что тупо но допустим) - она обращается к владельцу, владелец вызывает контроллер сессии и вновь происходит групповая операция. Каждый элемент легко протестировать, синглтоном является только энтрипоинт в сессию, можешь подучить dependency injection для облегчения проброса зависимостей вглубь веток. Программа должна быть похожа либо на дерево, либо на одноуровневое горизонтальное поле пшеницы(данных) по которому ездит исполняемый трактор (или много тракторов)
Анонимус, помни - сигналы - это просто заплатка прикрывающая дерьмовую архитектуру. Они очень просты, выглядят легко, казалось бы - надо чтобы одна ветка программы заставила другую её ветку сделать что-то, что другая ветка сама по себе бы и не собиралась делать. Но в этот момент ты на ровном месте формируешь сайд-эффект, который неформально в рантайме связывает то, что связанным быть никак не должно, это даже хуже чем синглтон, его зависимости хотябы отслеживаемы.
У карт есть обладатель, у обладателя есть level/session controller, у level/session controller есть gamecontainer в рамках которого игровая сессия имеет уникальный ид. Взаимодействие карт происходит через статический код, куда передается набор обладателей карт, взаимодействующих в данный момент, над ними производятся вычисления, вызываются методы обновления переданных в этот статический код обьектов и так происходит игровой процесс взаимодействия карт. Если карта сама по себе пожелает что-то сделать (что тупо но допустим) - она обращается к владельцу, владелец вызывает контроллер сессии и вновь происходит групповая операция. Каждый элемент легко протестировать, синглтоном является только энтрипоинт в сессию, можешь подучить dependency injection для облегчения проброса зависимостей вглубь веток. Программа должна быть похожа либо на дерево, либо на одноуровневое горизонтальное поле пшеницы(данных) по которому ездит исполняемый трактор (или много тракторов)
>>27601
Сигналы это ивенты. Сигналами ивенты впервые назвали в GTK, чтобы не как в винде. Дальше не читал бред мультикнопочникотона.
> Анонимус, помни - сигналы - это просто
Сигналы это ивенты. Сигналами ивенты впервые назвали в GTK, чтобы не как в винде. Дальше не читал бред мультикнопочникотона.
>>27608 (Del)
Ну в годоте можно без сигналов.
>>27601
Чек. Программа уже похожа на дереве. Просто управляешь любыми нодами из корневого скрипта. А что не так? А что такое?
Ну в годоте можно без сигналов.
>>27601
> Программа должна быть похожа либо на дерево
Чек. Программа уже похожа на дереве. Просто управляешь любыми нодами из корневого скрипта. А что не так? А что такое?
>>27614 (Del)
Причем тут сигналы? Я тебе говорю, управляешь всеми нодами из корня. Всё. Никаких сигналов.
Причем тут сигналы? Я тебе говорю, управляешь всеми нодами из корня. Всё. Никаких сигналов.
>>27618 (Del)
Ну пока он не вернулся, я и законтрил твой вредный совет с охуительными историями про вред сигналов.
Ну пока он не вернулся, я и законтрил твой вредный совет с охуительными историями про вред сигналов.
>>27601
База. Пост approved by бывший менеджер из АА-конторы, который за best practice и против синглтонов.
Сигналы мощная и гибкая вещь, но на отъебись ими пользоваться не получится, нужно делать к ним устойчивую архитектуру на стейт машинах, уметь отбрасывать уже невалидные события прилетевшие после смены стейта. Вот сколько мне присылали последних проектов на проверку, у всех одни и те же баги - например у кого то меню зависает и остается на экране когда уже игра идет, у кого-то после выигрыша может прилететь тик урона и одновременно показать надпись проигрыш.
Ну и конечно с сигналами надо быть вдвое внимательнее, чем с функциями, чтобы не отправлять сигнал который никто не ловит, и наоборот ловить сигналы, которые никто не отправляет. В моей иерархии сигналы где-то посередине между нормальными функциями и вызовом "по строке", которая вообще ненадежная как карточный домик.
База. Пост approved by бывший менеджер из АА-конторы, который за best practice и против синглтонов.
Сигналы мощная и гибкая вещь, но на отъебись ими пользоваться не получится, нужно делать к ним устойчивую архитектуру на стейт машинах, уметь отбрасывать уже невалидные события прилетевшие после смены стейта. Вот сколько мне присылали последних проектов на проверку, у всех одни и те же баги - например у кого то меню зависает и остается на экране когда уже игра идет, у кого-то после выигрыша может прилететь тик урона и одновременно показать надпись проигрыш.
Ну и конечно с сигналами надо быть вдвое внимательнее, чем с функциями, чтобы не отправлять сигнал который никто не ловит, и наоборот ловить сигналы, которые никто не отправляет. В моей иерархии сигналы где-то посередине между нормальными функциями и вызовом "по строке", которая вообще ненадежная как карточный домик.
>>27621
Твой вредный контр отменен и перекрыт двумя полезными историями про вред сигналов.
Твой вредный контр отменен и перекрыт двумя полезными историями про вред сигналов.
28 Кб, 423x215Это типа советы как проебать годы и нихуя не сделать? Не пользуйтесь удобными инструментами которые дает вам движок, велосипедьте свои, а лучше вообще свой движок, и обязательно с изи возможностью переключить всю игру в любой момент на мультиплеер и обратно по требованию левой пятки вчера нанятого сегодня уже бывшего манагера из А-конторы. А на обед вейлгард.
340 Кб, 760x629>>27633
Там кстати на днях еще один десятилетний мегастрой наебнулся. Не помогли ни многомиллионные инвестиции от Riot Games, ни выкуп ими всей компании, ни награды авансом. Зато пару раз с нуля успели движок переписать, переделать всю архитектуру, и скоп крип такой заебенить что сами охуели. При этом ни одной публичной версии так и не выпустили, в отличии майнкрафта, играбельного буквально с пустых кубов. "Либо релизнем полную и идеальную 100/10 игру, либо ничего, никаких компромиссов, ничего не вырежем, у нас же гениальный ВИЖН".
Шизка и понты точь-в-точь как у кое-кого из местных ноудевов.
Там кстати на днях еще один десятилетний мегастрой наебнулся. Не помогли ни многомиллионные инвестиции от Riot Games, ни выкуп ими всей компании, ни награды авансом. Зато пару раз с нуля успели движок переписать, переделать всю архитектуру, и скоп крип такой заебенить что сами охуели. При этом ни одной публичной версии так и не выпустили, в отличии майнкрафта, играбельного буквально с пустых кубов. "Либо релизнем полную и идеальную 100/10 игру, либо ничего, никаких компромиссов, ничего не вырежем, у нас же гениальный ВИЖН".
Шизка и понты точь-в-точь как у кое-кого из местных ноудевов.
>>27633
На самом деле нормально написанная игра позволяет себя переключать в оффлайн/онлайн по желанию пятки, да. А ecs так и вовсе позволяет за дни мерджить серверную логику с клиентской и датамодель сервера с датамоделью клиента. Хотя конечно не бесплатно, давать такое вкатуну бесполезная трата времени. Но ты скорее всего либо безыгорка либо джем энжоер, поскольку даже не понимаешь сути проблемы которую формируют сигналы и почему сайд эффекты (в частности неуправляемые сайд эффекты - их появление зависит текущего от состояния приложения) так опасны для конечного продукта.
На самом деле нормально написанная игра позволяет себя переключать в оффлайн/онлайн по желанию пятки, да. А ecs так и вовсе позволяет за дни мерджить серверную логику с клиентской и датамодель сервера с датамоделью клиента. Хотя конечно не бесплатно, давать такое вкатуну бесполезная трата времени. Но ты скорее всего либо безыгорка либо джем энжоер, поскольку даже не понимаешь сути проблемы которую формируют сигналы и почему сайд эффекты (в частности неуправляемые сайд эффекты - их появление зависит текущего от состояния приложения) так опасны для конечного продукта.
>>27644
Не отвлекайся, тебе там архитектуру мультиплеерных кнопок на передел привезли, снова. Говорят у них серверная датамодель не та.
Не отвлекайся, тебе там архитектуру мультиплеерных кнопок на передел привезли, снова. Говорят у них серверная датамодель не та.
>>27633
Это тебе к синглтонщику. У него много антипрактик.
>Это типа советы как проебать годы и нихуя не сделать?
Это тебе к синглтонщику. У него много антипрактик.
>>27646
Не, это мне к тебе, маневрятор. Сейчас наймем манагера из а-конторы и будем под его гениальным хлыстом лет 10 яйца вылизывать. Может на том свете зачтется.
Не, это мне к тебе, маневрятор. Сейчас наймем манагера из а-конторы и будем под его гениальным хлыстом лет 10 яйца вылизывать. Может на том свете зачтется.
>>27645
Ты меня с каким-то шизиком перепутал. Мультиплеерная кнопка это плод болезной фантазии больного RPC головного мозга. Которые кстати тоже частный случай событий. Интерфейс отдельно, шина сетевых событий отдельно, игровые сущности в рамках контейнера игровой сессии отдельно, ui элементы связанные с игровыми сущностями живут в контейнерах, которые им предоставляет интерфейс. Соответственно любая кнопка появление которой приходит из игровой сессии живет пока жива игровая сессия и обычно появляется не по мановению rpc, а по клиентской реакции на изменение датамодели из сервера. Ладно, понесло меня уже.
Ты меня с каким-то шизиком перепутал. Мультиплеерная кнопка это плод болезной фантазии больного RPC головного мозга. Которые кстати тоже частный случай событий. Интерфейс отдельно, шина сетевых событий отдельно, игровые сущности в рамках контейнера игровой сессии отдельно, ui элементы связанные с игровыми сущностями живут в контейнерах, которые им предоставляет интерфейс. Соответственно любая кнопка появление которой приходит из игровой сессии живет пока жива игровая сессия и обычно появляется не по мановению rpc, а по клиентской реакции на изменение датамодели из сервера. Ладно, понесло меня уже.
>>27651
Мультиплеерная кнопка вообще не про годот, это про фундаментальное ограничение современной винды.
Мультиплеерная кнопка вообще не про годот, это про фундаментальное ограничение современной винды.
Мультиплеерная кнопка это вообще не про код. Это философия, стиль жизни.
>>27649
Тогда тебе придется поторопиться, потому что у меня на днях два собеса и ты уже будешь третьим в очереди.
Тогда тебе придется поторопиться, потому что у меня на днях два собеса и ты уже будешь третьим в очереди.
>>27660
За пару дней в двух местах успеешь поработать и снова оказаться на улице? Талантище. Мы вам перезвоним.
За пару дней в двух местах успеешь поработать и снова оказаться на улице? Талантище. Мы вам перезвоним.
516 Кб, 888x499Делойте
515 Кб, 1920x1080Товарисчи, у меня куб не перемещается, если мышкой трясти, вот этот вот жёлтый треугольник влияет на это или нет?
Гугл Джемини скрипт написал, куб видно, но он стоит, ошибок не видно.
Гугл Джемини скрипт написал, куб видно, но он стоит, ошибок не видно.
>>27700
Влияет. Форма должна быть чайлдом физического объекта (например RigidBody или CharacterBody), а ты прикрепил к визуальному мешу.
Влияет. Форма должна быть чайлдом физического объекта (например RigidBody или CharacterBody), а ты прикрепил к визуальному мешу.
>>27700
Смотря как ты собираешься двигать свой куб. Коллижн шейп нужен чтобы придать физическую коллизию Area/Rigid/Character/Static телам. А у тебя шейп находится внутри меша, меш это просто графический 3д объект.
Попробуй такую структуру:
- Area
-- CollisionShape
-- MeshInstance
Тогда, если твой вайбкод jcbkbn, Area должно задетектить коллизию (ray_pickable) используя форму заданную с помощью CollisionShape, и сдвинуться с места, а вместе с ним и его дети - меш и коллижн шейп.
Смотря как ты собираешься двигать свой куб. Коллижн шейп нужен чтобы придать физическую коллизию Area/Rigid/Character/Static телам. А у тебя шейп находится внутри меша, меш это просто графический 3д объект.
Попробуй такую структуру:
- Area
-- CollisionShape
-- MeshInstance
Тогда, если твой вайбкод jcbkbn, Area должно задетектить коллизию (ray_pickable) используя форму заданную с помощью CollisionShape, и сдвинуться с места, а вместе с ним и его дети - меш и коллижн шейп.
147 Кб, 943x719>>27067
Чет челик тут пишет сделал и слишком сложно настраивать, под каждую сцену придется.
Чет челик тут пишет сделал и слишком сложно настраивать, под каждую сцену придется.
>>27711
Чел, за нейронками подчищать неинтересно.
Чел, за нейронками подчищать неинтересно.
>>27278
Ненужно. Разберешь, а потом опять собирать взад вперед, вместо этого учись пользоваться map/reduce
Ненужно. Разберешь, а потом опять собирать взад вперед, вместо этого учись пользоваться map/reduce
>>27640
Ничего, свой на Godot запилим!
https://reddit.com/r/HytaleInfo/comments/1ljd3ic/comment/mziuaic/
Обидно вообще-то...
>мегастрой наебнулся
Ничего, свой на Godot запилим!
https://reddit.com/r/HytaleInfo/comments/1ljd3ic/comment/mziuaic/
>кое-кого из местных ноудевов
Обидно вообще-то...
>>27742
Нужен интерфейс Steamworks SDK:
https://partner.steamgames.com/doc/home
Есть готовые бесплатные ассеты, но я не пробовал:
https://godotengine.org/asset-library/asset?filter=Steam
https://github.com/GodotSteam/GodotSteam
Нужен интерфейс Steamworks SDK:
https://partner.steamgames.com/doc/home
Есть готовые бесплатные ассеты, но я не пробовал:
https://godotengine.org/asset-library/asset?filter=Steam
https://github.com/GodotSteam/GodotSteam
17 Кб, 624x170>>27278
Эмм... А это как?
> за 4 года разраб не осилил создание списка в 1 строчку?
> github.com/godotengine/godot-proposals/issues/2972
Эмм... А это как?
>>27286
В чём проблема? Какая "ситуация" может мешать подсвечиванию карты в карточных играх? Лучше беспокоился бы о том, кто руководит движением.
Зачем "через всё дерево"? Можно так, например:
Игровая сцена:
И т.д.
>Вот допустим при наведении на карту она должна выделяться. Сделать для этого функцию в скрипте карты? Но тогда она будет срабатывать каждый раз без оглядки на окружающую ситуацию.
В чём проблема? Какая "ситуация" может мешать подсвечиванию карты в карточных играх? Лучше беспокоился бы о том, кто руководит движением.
>Запихнуть код в корень сцены? Тогда придётся тянуть от карт сигналы через всё дерево сцены.
Зачем "через всё дерево"? Можно так, например:
>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
И т.д.
46 Кб, 408x439>>27286
обрабатываем вход/выход мыши
Заводим стейт-машину картам и задаём им стейт(ы) при котором(ых) карты реагируют на мышь (на инпут).
Ваще большинство проблем геймдева решается стейт-машиной. Кроме проблемы взрыва стейтов при заведении стейт-машины. Она решается заведением второй стейт-машины.
> Вот допустим при наведении на карту она должна выделяться.
обрабатываем вход/выход мыши
> Но тогда она будет срабатывать каждый раз без оглядки на окружающую ситуацию
Заводим стейт-машину картам и задаём им стейт(ы) при котором(ых) карты реагируют на мышь (на инпут).
Ваще большинство проблем геймдева решается стейт-машиной. Кроме проблемы взрыва стейтов при заведении стейт-машины. Она решается заведением второй стейт-машины.
272 Кб, 340x350>>27757
Давай, заводи свою стейт-машину, заводи это дерьмо.
Давай, заводи свою стейт-машину, заводи это дерьмо.
>>27601
Сигналы/события - это EDA, event-driven architecture. Чрезвычайно полезная вещь, избавляющая тебя от непрерывного запроса состояния других объектов.
Ты совершенно не понимаешь концепцию событий. События возникают внутри объекта и оповещают об изменении состояния объекта внешний мир, но не заставляют кого-либо реагировать на них.
Во-первых, EDA отличается тем, что максимально отвязывает объекты друг от друга. Связывания не происходит, происходит лишь реакция на события.
Во-вторых, ты делаешь это осознанно - по плану.
Синглтон - это глобальная сущность, которую можно вызывать из любого участка кода, поэтому синглтон максимально связывает твой код, превращая всё приложение в непонятную лапшу из зависимостей. Аккуратно им пользоваться сложнее, чем сделать аккуратную архитектуру на событиях (сигналах).
Да, именно поэтому нужно использовать сигналы.
Это противоречит ООП, т.е. усложняет поддержку.
>>27608 (Del)
Ты не понимаешь сути событий. Позволь объяснить.
Но начнём с базовых концепций:
Переменная/объект: что мы ИМЕЕМ?
Функция/метод: что мы СДЕЛАЕМ?
Событие/сигнал: что ПРОИЗОШЛО?
Пример:
Человек - это объект.
Идти - это действие объекта.
Упал - это изменение состояния.
Если нам нужно что-то, мы берём объект.
Если нужно что-то сделать - вызываем метод.
Если нужно узнать о том, что может произойти в будущем - мы берём объект и подписываем один из собственных (или чужих) методов на событие, что объявляется выбранным нами объектом.
Проблема возникает из-за непонимания того, что случившееся событие - это не призыв к действию, а оповещение о том, что какое-то действие совершено. Событие никого ни к чему не принуждает, и тебя, как разработчика объекта, совершенно не волнует, кто в будущем может отреагировать на твоё событие. Но выставить событие наружу ты должен, если по плану необходимо знать о том, что что-то где-то произошло.
Пример роли событий из реальной игры: YandereDev заставлял NPC в Yandere Simulator проверять 60 раз в секунду игровые часы, чтобы узнать, не пора ли NPC проследовать в кабинет на урок. Понятно, что для 10 подобных NPC получается уже 600 запросов каждую секунду, на протяжении всей игры. Как решить эту проблему? Игровые часы должны иметь событие "начинается урок (математики, физики и т.д.)", а NPC - подписываться на событие часов, например, так:
Теперь, когда игровые часы отсчитывают время и обнаруживают, что пора начать урок, NPC получают однократное уведомление и реагируют на него, не опрашивая часы 60 раз в секунду как раньше.
Почему EDA отвязывает объекты друг от друга? Для сравнения, без использования событий предыдущую проблему можно было бы решить таким образом:
Да, этот код раздает оповещения ученикам лишь по необходимости, избавляя от проблемы 60 запросов в секунду от каждого ученика. Но теперь наши "часы" совершенно внезапно знают обо всех учениках. Если необходимо добавить учителей, придётся объявлять учителей как учеников или менять код "часов". Если в будущем мы решим изменить код ученика, мы будем вынуждены изменить код "часов", т.к. он напрямую обращается к коду ученика и зависит от него. Если следовать EDA, мы делаем наш Clock независимым:
Как видите, код практически тот же, но теперь он не озабочен никакими учениками и учителями - они не касаются наших часов, поскольку задача часов - подсчитывать время и оповещать о начале урока.
В ситуации с карточной игрой: карта имеет своего владельца, но может и не иметь - карта не должна напрямую обращаться к своему владельцу. Т.е. если происходит событие с картой (наведение курсора, перемещение по полю и т.д.), карта должна сделать оповещение об этом, но кто на него среагирует - нам безразлично на уровне абстракции данной карты.
Владелец (менеджер) карты может вызывать у неё определённые действия, такие как "включи обводку", отвечая на событие карты "наведён курсор мыши", но владелец не обязан это делать и может игнорировать события, происходящие с картой. Карта же способна проявлять поведение без событий, как, например, проигрывание эффектов карты (блёстки и т.п.).
Это позволяет использовать карту отдельно - хоть и с ограниченным функционалом, а ещё написать новый (отдельный) менеджер для уже существующих карт. Например, менеджер поля (где лежат выложенные игроками карты) может отличаться от руки игрока, но обработка событий карты производится обоими (по необходимости, т.е. если они владеют картой).
Всё очень просто, если понимать базу.
>сигналы - это просто заплатка
Сигналы/события - это EDA, event-driven architecture. Чрезвычайно полезная вещь, избавляющая тебя от непрерывного запроса состояния других объектов.
>надо чтобы одна ветка программы заставила другую её ветку сделать что-то, что другая ветка сама по себе бы и не собиралась делать
Ты совершенно не понимаешь концепцию событий. События возникают внутри объекта и оповещают об изменении состояния объекта внешний мир, но не заставляют кого-либо реагировать на них.
>ты на ровном месте формируешь сайд-эффект, который неформально в рантайме связывает то, что связанным быть никак не должно
Во-первых, EDA отличается тем, что максимально отвязывает объекты друг от друга. Связывания не происходит, происходит лишь реакция на события.
Во-вторых, ты делаешь это осознанно - по плану.
>синглтон, его зависимости хотябы отслеживаемы
Синглтон - это глобальная сущность, которую можно вызывать из любого участка кода, поэтому синглтон максимально связывает твой код, превращая всё приложение в непонятную лапшу из зависимостей. Аккуратно им пользоваться сложнее, чем сделать аккуратную архитектуру на событиях (сигналах).
>Программа должна быть похожа на дерево
Да, именно поэтому нужно использовать сигналы.
>одноуровневое горизонтальное поле данных
Это противоречит ООП, т.е. усложняет поддержку.
>>27608 (Del)
>Суть одна - инкапсуляция призыва к действию получател(я/ей) этого сигнала, к действию которое вызывается никак иначе кроме как этим сигналом.
Ты не понимаешь сути событий. Позволь объяснить.
Но начнём с базовых концепций:
Переменная/объект: что мы ИМЕЕМ?
Функция/метод: что мы СДЕЛАЕМ?
Событие/сигнал: что ПРОИЗОШЛО?
Пример:
Человек - это объект.
Идти - это действие объекта.
Упал - это изменение состояния.
Если нам нужно что-то, мы берём объект.
Если нужно что-то сделать - вызываем метод.
Если нужно узнать о том, что может произойти в будущем - мы берём объект и подписываем один из собственных (или чужих) методов на событие, что объявляется выбранным нами объектом.
Проблема возникает из-за непонимания того, что случившееся событие - это не призыв к действию, а оповещение о том, что какое-то действие совершено. Событие никого ни к чему не принуждает, и тебя, как разработчика объекта, совершенно не волнует, кто в будущем может отреагировать на твоё событие. Но выставить событие наружу ты должен, если по плану необходимо знать о том, что что-то где-то произошло.
Пример роли событий из реальной игры: 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])
Как видите, код практически тот же, но теперь он не озабочен никакими учениками и учителями - они не касаются наших часов, поскольку задача часов - подсчитывать время и оповещать о начале урока.
В ситуации с карточной игрой: карта имеет своего владельца, но может и не иметь - карта не должна напрямую обращаться к своему владельцу. Т.е. если происходит событие с картой (наведение курсора, перемещение по полю и т.д.), карта должна сделать оповещение об этом, но кто на него среагирует - нам безразлично на уровне абстракции данной карты.
Владелец (менеджер) карты может вызывать у неё определённые действия, такие как "включи обводку", отвечая на событие карты "наведён курсор мыши", но владелец не обязан это делать и может игнорировать события, происходящие с картой. Карта же способна проявлять поведение без событий, как, например, проигрывание эффектов карты (блёстки и т.п.).
Это позволяет использовать карту отдельно - хоть и с ограниченным функционалом, а ещё написать новый (отдельный) менеджер для уже существующих карт. Например, менеджер поля (где лежат выложенные игроками карты) может отличаться от руки игрока, но обработка событий карты производится обоими (по необходимости, т.е. если они владеют картой).
Всё очень просто, если понимать базу.
>>27601
Сигналы/события - это EDA, event-driven architecture. Чрезвычайно полезная вещь, избавляющая тебя от непрерывного запроса состояния других объектов.
Ты совершенно не понимаешь концепцию событий. События возникают внутри объекта и оповещают об изменении состояния объекта внешний мир, но не заставляют кого-либо реагировать на них.
Во-первых, EDA отличается тем, что максимально отвязывает объекты друг от друга. Связывания не происходит, происходит лишь реакция на события.
Во-вторых, ты делаешь это осознанно - по плану.
Синглтон - это глобальная сущность, которую можно вызывать из любого участка кода, поэтому синглтон максимально связывает твой код, превращая всё приложение в непонятную лапшу из зависимостей. Аккуратно им пользоваться сложнее, чем сделать аккуратную архитектуру на событиях (сигналах).
Да, именно поэтому нужно использовать сигналы.
Это противоречит ООП, т.е. усложняет поддержку.
>>27608 (Del)
Ты не понимаешь сути событий. Позволь объяснить.
Но начнём с базовых концепций:
Переменная/объект: что мы ИМЕЕМ?
Функция/метод: что мы СДЕЛАЕМ?
Событие/сигнал: что ПРОИЗОШЛО?
Пример:
Человек - это объект.
Идти - это действие объекта.
Упал - это изменение состояния.
Если нам нужно что-то, мы берём объект.
Если нужно что-то сделать - вызываем метод.
Если нужно узнать о том, что может произойти в будущем - мы берём объект и подписываем один из собственных (или чужих) методов на событие, что объявляется выбранным нами объектом.
Проблема возникает из-за непонимания того, что случившееся событие - это не призыв к действию, а оповещение о том, что какое-то действие совершено. Событие никого ни к чему не принуждает, и тебя, как разработчика объекта, совершенно не волнует, кто в будущем может отреагировать на твоё событие. Но выставить событие наружу ты должен, если по плану необходимо знать о том, что что-то где-то произошло.
Пример роли событий из реальной игры: YandereDev заставлял NPC в Yandere Simulator проверять 60 раз в секунду игровые часы, чтобы узнать, не пора ли NPC проследовать в кабинет на урок. Понятно, что для 10 подобных NPC получается уже 600 запросов каждую секунду, на протяжении всей игры. Как решить эту проблему? Игровые часы должны иметь событие "начинается урок (математики, физики и т.д.)", а NPC - подписываться на событие часов, например, так:
Теперь, когда игровые часы отсчитывают время и обнаруживают, что пора начать урок, NPC получают однократное уведомление и реагируют на него, не опрашивая часы 60 раз в секунду как раньше.
Почему EDA отвязывает объекты друг от друга? Для сравнения, без использования событий предыдущую проблему можно было бы решить таким образом:
Да, этот код раздает оповещения ученикам лишь по необходимости, избавляя от проблемы 60 запросов в секунду от каждого ученика. Но теперь наши "часы" совершенно внезапно знают обо всех учениках. Если необходимо добавить учителей, придётся объявлять учителей как учеников или менять код "часов". Если в будущем мы решим изменить код ученика, мы будем вынуждены изменить код "часов", т.к. он напрямую обращается к коду ученика и зависит от него. Если следовать EDA, мы делаем наш Clock независимым:
Как видите, код практически тот же, но теперь он не озабочен никакими учениками и учителями - они не касаются наших часов, поскольку задача часов - подсчитывать время и оповещать о начале урока.
В ситуации с карточной игрой: карта имеет своего владельца, но может и не иметь - карта не должна напрямую обращаться к своему владельцу. Т.е. если происходит событие с картой (наведение курсора, перемещение по полю и т.д.), карта должна сделать оповещение об этом, но кто на него среагирует - нам безразлично на уровне абстракции данной карты.
Владелец (менеджер) карты может вызывать у неё определённые действия, такие как "включи обводку", отвечая на событие карты "наведён курсор мыши", но владелец не обязан это делать и может игнорировать события, происходящие с картой. Карта же способна проявлять поведение без событий, как, например, проигрывание эффектов карты (блёстки и т.п.).
Это позволяет использовать карту отдельно - хоть и с ограниченным функционалом, а ещё написать новый (отдельный) менеджер для уже существующих карт. Например, менеджер поля (где лежат выложенные игроками карты) может отличаться от руки игрока, но обработка событий карты производится обоими (по необходимости, т.е. если они владеют картой).
Всё очень просто, если понимать базу.
>сигналы - это просто заплатка
Сигналы/события - это EDA, event-driven architecture. Чрезвычайно полезная вещь, избавляющая тебя от непрерывного запроса состояния других объектов.
>надо чтобы одна ветка программы заставила другую её ветку сделать что-то, что другая ветка сама по себе бы и не собиралась делать
Ты совершенно не понимаешь концепцию событий. События возникают внутри объекта и оповещают об изменении состояния объекта внешний мир, но не заставляют кого-либо реагировать на них.
>ты на ровном месте формируешь сайд-эффект, который неформально в рантайме связывает то, что связанным быть никак не должно
Во-первых, EDA отличается тем, что максимально отвязывает объекты друг от друга. Связывания не происходит, происходит лишь реакция на события.
Во-вторых, ты делаешь это осознанно - по плану.
>синглтон, его зависимости хотябы отслеживаемы
Синглтон - это глобальная сущность, которую можно вызывать из любого участка кода, поэтому синглтон максимально связывает твой код, превращая всё приложение в непонятную лапшу из зависимостей. Аккуратно им пользоваться сложнее, чем сделать аккуратную архитектуру на событиях (сигналах).
>Программа должна быть похожа на дерево
Да, именно поэтому нужно использовать сигналы.
>одноуровневое горизонтальное поле данных
Это противоречит ООП, т.е. усложняет поддержку.
>>27608 (Del)
>Суть одна - инкапсуляция призыва к действию получател(я/ей) этого сигнала, к действию которое вызывается никак иначе кроме как этим сигналом.
Ты не понимаешь сути событий. Позволь объяснить.
Но начнём с базовых концепций:
Переменная/объект: что мы ИМЕЕМ?
Функция/метод: что мы СДЕЛАЕМ?
Событие/сигнал: что ПРОИЗОШЛО?
Пример:
Человек - это объект.
Идти - это действие объекта.
Упал - это изменение состояния.
Если нам нужно что-то, мы берём объект.
Если нужно что-то сделать - вызываем метод.
Если нужно узнать о том, что может произойти в будущем - мы берём объект и подписываем один из собственных (или чужих) методов на событие, что объявляется выбранным нами объектом.
Проблема возникает из-за непонимания того, что случившееся событие - это не призыв к действию, а оповещение о том, что какое-то действие совершено. Событие никого ни к чему не принуждает, и тебя, как разработчика объекта, совершенно не волнует, кто в будущем может отреагировать на твоё событие. Но выставить событие наружу ты должен, если по плану необходимо знать о том, что что-то где-то произошло.
Пример роли событий из реальной игры: 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])
Как видите, код практически тот же, но теперь он не озабочен никакими учениками и учителями - они не касаются наших часов, поскольку задача часов - подсчитывать время и оповещать о начале урока.
В ситуации с карточной игрой: карта имеет своего владельца, но может и не иметь - карта не должна напрямую обращаться к своему владельцу. Т.е. если происходит событие с картой (наведение курсора, перемещение по полю и т.д.), карта должна сделать оповещение об этом, но кто на него среагирует - нам безразлично на уровне абстракции данной карты.
Владелец (менеджер) карты может вызывать у неё определённые действия, такие как "включи обводку", отвечая на событие карты "наведён курсор мыши", но владелец не обязан это делать и может игнорировать события, происходящие с картой. Карта же способна проявлять поведение без событий, как, например, проигрывание эффектов карты (блёстки и т.п.).
Это позволяет использовать карту отдельно - хоть и с ограниченным функционалом, а ещё написать новый (отдельный) менеджер для уже существующих карт. Например, менеджер поля (где лежат выложенные игроками карты) может отличаться от руки игрока, но обработка событий карты производится обоими (по необходимости, т.е. если они владеют картой).
Всё очень просто, если понимать базу.
>>27768
Мои игры на компьютерах и смартфонах игроков. Старайся лучше и тоже сделаешь игру.
Мои игры на компьютерах и смартфонах игроков. Старайся лучше и тоже сделаешь игру.
>>27764
И не лень тебе жирного кормить? Я его просто обоссал и пошёл игры дальше делать. И ты так делай. Игры делай.
И не лень тебе жирного кормить? Я его просто обоссал и пошёл игры дальше делать. И ты так делай. Игры делай.
>>27780 (Del)
Шину событий заводишь в корне дерева и наслаждаешься. Сигналы в годоте отписывать не нужно, хотя возможность и АПИ для этого есть (дисконнект). Как только источник подписки выгрузился, подписка отписалась сама. Этим годотовская реализация событий отличается от прочих. Безопасные подписки.
Так что просто заводим шину сигналов на верхних уровнях (можно прямо в майнлупе), и хуярим на ней контролируемые централизованные сигналы, без лапши и прочей хуйни.
> моего баттхерта и предлагаемых ограничений по поводу проблемы событий видимо не понять
Шину событий заводишь в корне дерева и наслаждаешься. Сигналы в годоте отписывать не нужно, хотя возможность и АПИ для этого есть (дисконнект). Как только источник подписки выгрузился, подписка отписалась сама. Этим годотовская реализация событий отличается от прочих. Безопасные подписки.
Так что просто заводим шину сигналов на верхних уровнях (можно прямо в майнлупе), и хуярим на ней контролируемые централизованные сигналы, без лапши и прочей хуйни.
>>27772
Я не он, но потому что не хочется связывать свое ирл с харкачем. Но выше там кто-то поездовый хоррор свой показывал, а в прошлых тредах чуваки со своими Noesys или как-то так.
Я не он, но потому что не хочется связывать свое ирл с харкачем. Но выше там кто-то поездовый хоррор свой показывал, а в прошлых тредах чуваки со своими Noesys или как-то так.
Подскажите вот что. У меня уровень, состоящий из пары тысяч сцен. В игре ок, шустро. В редакторе рендерится ок, шустро. Проблема - открытие этого уровня в редакторе, или переключение вкладок с уровня на что угодно и обратно, занимает секунд 5, без преувеличений, и при активной работе над ассетами приходится прыгать туда-сюда по вкладкам, въебывая кучу времени на подгрузку.
Пробовал чистить кеш, пробовал скрывать ноды, пробовал сохранять их как подсцены. Единственное что помогает - полное удаление значительной части сцен, из которых сделан уровень. Может есть способ научить годот не выгружать вкладку при переключении из нее?
Пробовал чистить кеш, пробовал скрывать ноды, пробовал сохранять их как подсцены. Единственное что помогает - полное удаление значительной части сцен, из которых сделан уровень. Может есть способ научить годот не выгружать вкладку при переключении из нее?
>>27810
Тогда надо понять что вызывает тряску, либо открывай по редактору на сцену и работай так.
Тогда надо понять что вызывает тряску, либо открывай по редактору на сцену и работай так.
>>27807
Да он и не должен выгружать, дело в чём-то другом, возможно в рендеререре, похоже не хватает памяти, если у тебя 3D нажми на три точки слева сверху в окне с 3д и поставь Half Resolution
Да он и не должен выгружать, дело в чём-то другом, возможно в рендеререре, похоже не хватает памяти, если у тебя 3D нажми на три точки слева сверху в окне с 3д и поставь Half Resolution
>>27823
Обычные такие, средненькие.
Обычные такие, средненькие.
>>27834
Слышал только Годотобоги.
Слышал только Годотобоги.
189 Кб, 703x696Где волшебный нескучный лучший курс с Ютуба на русише для полного вката с нуля мона глянуть?
Желательно, чтобы порекомендовали уже спецы.
Движку просто куча лет и куча пользователей, может, что на русише норм появилось.
Желательно, чтобы порекомендовали уже спецы.
Движку просто куча лет и куча пользователей, может, что на русише норм появилось.
>>27843
Яндекс браузер тебе переведет и озвучит. А лучше сам учи. Весь русскоязычный околоайтишный контент отстает от мейнстрима на пару лет минимум.
Яндекс браузер тебе переведет и озвучит. А лучше сам учи. Весь русскоязычный околоайтишный контент отстает от мейнстрима на пару лет минимум.
>>27775 (Del)
1. Создай сцену.
2. Добавь Button.
3. Нажми F6.
4. Нажми Button.
Godot крашнулся с ошибкой "но ты обязан!.."?
Нет, кнопка нажалась, но Godot не крашнулся.
Значит, ты не обязан реагировать на кнопку.
Событие "нажатие кнопки пользователем" обычно приводит к какому-то "эффекту", но этот эффект - не нежелательный, а запланированный дизайнером.
Без события ты будешь 60 раз в секунду делать принудительную проверку "кнопка нажата?", либо сделаешь код кнопки владельцем совершенно не относящихся к кнопкам объектов (будет лапша).
События происходят обычно в "нижних" отделах приложения (листьях дерева), и поэтому не могут прекратить появляться. Ты же не меняешь код беспорядочно, верно? А если ты в команде, то ты, естественно, должен договариваться о внутренних интерфейсах и не изменять их без предупреждения.
Обычно, когда ты используешь какое-то событие (подписываешься на него), оно исходит из уже разработанного компонента и не будет меняться существенным образом (т.е. интерфейс стабилен).
Покажи пример, где там твоя логика нарушилась. Не представляю, зачем ты выстроил какое-то домино и жалуешься теперь, что оно сработало как должно. Я попробую объяснить, как это нужно было делать.
Так ты не делай "if !random(): bug()" в коде, лалка.
Событийно ориентированная архитектура позволяет протестировать каждый из компонентов программы полностью независимо друг от друга, гарантировать корректность их работы. Уже ПОТОМ ты будешь как дизайнер связывать имеющиеся у тебя и на 100% протестированные компоненты во что-то большее (и тестировать это "большее" как цельный компонент).
Разработка снизу вверх получается - от меньших компонентов (кнопки, карты, студенты) к большим (графический интерфейс, стол с картами, школа). Отличается от разработки сверху вниз повышенной гибкостью архитектуры и работоспособностью игры буквально с самого старта, т.к. не опирается на ещё отсутствующие системы высшего уровня.
Без событий разрабатывать снизу вверх сложно, т.к. приходится залазить в кишки мелких компонентов. События позволяют мелким компонентам сообщить крупным компонентам о том, что у них произошло. Разрабатывать сверху вниз через события тоже возможно, но в геймдеве обычно всё снизу вверх - необходимо иметь рабочую игру как можно раньше.
>>27776 (Del)
Это так веб-макаки сегодня дрочат? Я просто не интересуюсь айти за пределами геймдева, извини.
События - это расширение ООП. Без принципов ООП далеко не уедешь, а без событий некомфортно ехать.
>Зачем они вообще нужны если никто не обязан на них реагировать? Или может всё таки обязан
1. Создай сцену.
2. Добавь Button.
3. Нажми F6.
4. Нажми Button.
Godot крашнулся с ошибкой "но ты обязан!.."?
Нет, кнопка нажалась, но Godot не крашнулся.
Значит, ты не обязан реагировать на кнопку.
>приводит к образованию сайд эффектов
Событие "нажатие кнопки пользователем" обычно приводит к какому-то "эффекту", но этот эффект - не нежелательный, а запланированный дизайнером.
Без события ты будешь 60 раз в секунду делать принудительную проверку "кнопка нажата?", либо сделаешь код кнопки владельцем совершенно не относящихся к кнопкам объектов (будет лапша).
>эти события по каким либо причинам перестанут появляться, или начнут появляться не так
События происходят обычно в "нижних" отделах приложения (листьях дерева), и поэтому не могут прекратить появляться. Ты же не меняешь код беспорядочно, верно? А если ты в команде, то ты, естественно, должен договариваться о внутренних интерфейсах и не изменять их без предупреждения.
Обычно, когда ты используешь какое-то событие (подписываешься на него), оно исходит из уже разработанного компонента и не будет меняться существенным образом (т.е. интерфейс стабилен).
>каскадное нарушение логики работы всех обьектов
Покажи пример, где там твоя логика нарушилась. Не представляю, зачем ты выстроил какое-то домино и жалуешься теперь, что оно сработало как должно. Я попробую объяснить, как это нужно было делать.
>происходить не постоянно, т.н. плавающие баги
Так ты не делай "if !random(): bug()" в коде, лалка.
Событийно ориентированная архитектура позволяет протестировать каждый из компонентов программы полностью независимо друг от друга, гарантировать корректность их работы. Уже ПОТОМ ты будешь как дизайнер связывать имеющиеся у тебя и на 100% протестированные компоненты во что-то большее (и тестировать это "большее" как цельный компонент).
Разработка снизу вверх получается - от меньших компонентов (кнопки, карты, студенты) к большим (графический интерфейс, стол с картами, школа). Отличается от разработки сверху вниз повышенной гибкостью архитектуры и работоспособностью игры буквально с самого старта, т.к. не опирается на ещё отсутствующие системы высшего уровня.
Без событий разрабатывать снизу вверх сложно, т.к. приходится залазить в кишки мелких компонентов. События позволяют мелким компонентам сообщить крупным компонентам о том, что у них произошло. Разрабатывать сверху вниз через события тоже возможно, но в геймдеве обычно всё снизу вверх - необходимо иметь рабочую игру как можно раньше.
>>27776 (Del)
>обьекты по цепочке внедренных владельцев либо сами делают что-то, либо вызывают код у своих владельцев который делает что-то, либо стучат в какой-то из синглтонов
Это так веб-макаки сегодня дрочат? Я просто не интересуюсь айти за пределами геймдева, извини.
>Слышал про ООП принципы?
События - это расширение ООП. Без принципов ООП далеко не уедешь, а без событий некомфортно ехать.
>>27775 (Del)
1. Создай сцену.
2. Добавь Button.
3. Нажми F6.
4. Нажми Button.
Godot крашнулся с ошибкой "но ты обязан!.."?
Нет, кнопка нажалась, но Godot не крашнулся.
Значит, ты не обязан реагировать на кнопку.
Событие "нажатие кнопки пользователем" обычно приводит к какому-то "эффекту", но этот эффект - не нежелательный, а запланированный дизайнером.
Без события ты будешь 60 раз в секунду делать принудительную проверку "кнопка нажата?", либо сделаешь код кнопки владельцем совершенно не относящихся к кнопкам объектов (будет лапша).
События происходят обычно в "нижних" отделах приложения (листьях дерева), и поэтому не могут прекратить появляться. Ты же не меняешь код беспорядочно, верно? А если ты в команде, то ты, естественно, должен договариваться о внутренних интерфейсах и не изменять их без предупреждения.
Обычно, когда ты используешь какое-то событие (подписываешься на него), оно исходит из уже разработанного компонента и не будет меняться существенным образом (т.е. интерфейс стабилен).
Покажи пример, где там твоя логика нарушилась. Не представляю, зачем ты выстроил какое-то домино и жалуешься теперь, что оно сработало как должно. Я попробую объяснить, как это нужно было делать.
Так ты не делай "if !random(): bug()" в коде, лалка.
Событийно ориентированная архитектура позволяет протестировать каждый из компонентов программы полностью независимо друг от друга, гарантировать корректность их работы. Уже ПОТОМ ты будешь как дизайнер связывать имеющиеся у тебя и на 100% протестированные компоненты во что-то большее (и тестировать это "большее" как цельный компонент).
Разработка снизу вверх получается - от меньших компонентов (кнопки, карты, студенты) к большим (графический интерфейс, стол с картами, школа). Отличается от разработки сверху вниз повышенной гибкостью архитектуры и работоспособностью игры буквально с самого старта, т.к. не опирается на ещё отсутствующие системы высшего уровня.
Без событий разрабатывать снизу вверх сложно, т.к. приходится залазить в кишки мелких компонентов. События позволяют мелким компонентам сообщить крупным компонентам о том, что у них произошло. Разрабатывать сверху вниз через события тоже возможно, но в геймдеве обычно всё снизу вверх - необходимо иметь рабочую игру как можно раньше.
>>27776 (Del)
Это так веб-макаки сегодня дрочат? Я просто не интересуюсь айти за пределами геймдева, извини.
События - это расширение ООП. Без принципов ООП далеко не уедешь, а без событий некомфортно ехать.
>Зачем они вообще нужны если никто не обязан на них реагировать? Или может всё таки обязан
1. Создай сцену.
2. Добавь Button.
3. Нажми F6.
4. Нажми Button.
Godot крашнулся с ошибкой "но ты обязан!.."?
Нет, кнопка нажалась, но Godot не крашнулся.
Значит, ты не обязан реагировать на кнопку.
>приводит к образованию сайд эффектов
Событие "нажатие кнопки пользователем" обычно приводит к какому-то "эффекту", но этот эффект - не нежелательный, а запланированный дизайнером.
Без события ты будешь 60 раз в секунду делать принудительную проверку "кнопка нажата?", либо сделаешь код кнопки владельцем совершенно не относящихся к кнопкам объектов (будет лапша).
>эти события по каким либо причинам перестанут появляться, или начнут появляться не так
События происходят обычно в "нижних" отделах приложения (листьях дерева), и поэтому не могут прекратить появляться. Ты же не меняешь код беспорядочно, верно? А если ты в команде, то ты, естественно, должен договариваться о внутренних интерфейсах и не изменять их без предупреждения.
Обычно, когда ты используешь какое-то событие (подписываешься на него), оно исходит из уже разработанного компонента и не будет меняться существенным образом (т.е. интерфейс стабилен).
>каскадное нарушение логики работы всех обьектов
Покажи пример, где там твоя логика нарушилась. Не представляю, зачем ты выстроил какое-то домино и жалуешься теперь, что оно сработало как должно. Я попробую объяснить, как это нужно было делать.
>происходить не постоянно, т.н. плавающие баги
Так ты не делай "if !random(): bug()" в коде, лалка.
Событийно ориентированная архитектура позволяет протестировать каждый из компонентов программы полностью независимо друг от друга, гарантировать корректность их работы. Уже ПОТОМ ты будешь как дизайнер связывать имеющиеся у тебя и на 100% протестированные компоненты во что-то большее (и тестировать это "большее" как цельный компонент).
Разработка снизу вверх получается - от меньших компонентов (кнопки, карты, студенты) к большим (графический интерфейс, стол с картами, школа). Отличается от разработки сверху вниз повышенной гибкостью архитектуры и работоспособностью игры буквально с самого старта, т.к. не опирается на ещё отсутствующие системы высшего уровня.
Без событий разрабатывать снизу вверх сложно, т.к. приходится залазить в кишки мелких компонентов. События позволяют мелким компонентам сообщить крупным компонентам о том, что у них произошло. Разрабатывать сверху вниз через события тоже возможно, но в геймдеве обычно всё снизу вверх - необходимо иметь рабочую игру как можно раньше.
>>27776 (Del)
>обьекты по цепочке внедренных владельцев либо сами делают что-то, либо вызывают код у своих владельцев который делает что-то, либо стучат в какой-то из синглтонов
Это так веб-макаки сегодня дрочат? Я просто не интересуюсь айти за пределами геймдева, извини.
>Слышал про ООП принципы?
События - это расширение ООП. Без принципов ООП далеко не уедешь, а без событий некомфортно ехать.
ООП в игрострое не нужен.
>>27846
гэбня нинужна, хочу цру или китайцев на худой конец
нафиг, я буду учить тока, как игоры делоть и другие программы на годоте
не надо так шутить, плз
>Яндекс браузер тебе переведет и озвучит.
гэбня нинужна, хочу цру или китайцев на худой конец
>А лучше сам учи.
нафиг, я буду учить тока, как игоры делоть и другие программы на годоте
>Весь русскоязычный околоайтишный контент отстает от мейнстрима на пару лет минимум.
не надо так шутить, плз
>>27850
В лучшем случае ты просто не хочешь ничего делать и лепишь отмазки. В худшем залетел потраливалить. Отлетаешь в любом случае.
В лучшем случае ты просто не хочешь ничего делать и лепишь отмазки. В худшем залетел потраливалить. Отлетаешь в любом случае.
>>27821
Увы, не помогает. Долго думает на переключении даже если скрыть все элементы уровня. Более того - долго думает даже если я не в 3д редакторе, а в скрипт-редакторе, и переключаюсь на вкладку своего огромного уровня (оставаясь при этом в редакторе скриптов).
Увы, не помогает. Долго думает на переключении даже если скрыть все элементы уровня. Более того - долго думает даже если я не в 3д редакторе, а в скрипт-редакторе, и переключаюсь на вкладку своего огромного уровня (оставаясь при этом в редакторе скриптов).
>>27847
Это и есть минус о котором тебе твердили выше. Это тоже вид бага, неправильная подписка, только более трудно отлавливаемый чем ошибка в прямом обращении. (В реальной разработке как раз предпочитают чтобы был краш с логами чтобы сразу найти место ошибки - поскольку гдскрипт не компилируемый).
Буквально большинство экшн, реалтаймовых игр на годоте так и работают. Input.is_pressed(), Input.is_just_pressed(). Вот что полезно так это второе, паттерн Latch (задвижка) известный еще с 80-х. Когда нажатие выставляет флаг, и он остается взведенным пока не будет считан. А события притащены всякими веб макаками, ну есть определенные игры типа кликеров где с ними удобно, но подозреваю что это меньшинство.
Не делай в не относящихся, делай в нужных менеджерах.
>Godot крашнулся с ошибкой "но ты обязан!.."? Нет, кнопка нажалась, но Godot не крашнулся.
Это и есть минус о котором тебе твердили выше. Это тоже вид бага, неправильная подписка, только более трудно отлавливаемый чем ошибка в прямом обращении. (В реальной разработке как раз предпочитают чтобы был краш с логами чтобы сразу найти место ошибки - поскольку гдскрипт не компилируемый).
>Без события ты будешь 60 раз в секунду делать принудительную проверку "кнопка нажата?"
Буквально большинство экшн, реалтаймовых игр на годоте так и работают. Input.is_pressed(), Input.is_just_pressed(). Вот что полезно так это второе, паттерн Latch (задвижка) известный еще с 80-х. Когда нажатие выставляет флаг, и он остается взведенным пока не будет считан. А события притащены всякими веб макаками, ну есть определенные игры типа кликеров где с ними удобно, но подозреваю что это меньшинство.
>либо сделаешь код кнопки владельцем совершенно не относящихся к кнопкам объектов (будет лапша).
Не делай в не относящихся, делай в нужных менеджерах.
>>27785
Это буквально определение лапши. Потому что в эту шину все срут и неизвестно кто читает (еще и не то что им предназначалось, то есть они еще и лишнюю производительность тратят на отфильтровывание того что не для них).
>Так что просто заводим шину сигналов на верхних уровнях
Это буквально определение лапши. Потому что в эту шину все срут и неизвестно кто читает (еще и не то что им предназначалось, то есть они еще и лишнюю производительность тратят на отфильтровывание того что не для них).
>>27807
Это нормально и ожидаемо.
Я не знаю точно, так как не изучал соответствующие исходники, но насколько я понимаю, всё, что видно в редакторе - это ноды, да, точно такие же, как у тебя в интерфейсе игры. При переключении вкладок старая сцена удаляется из дерева, а новая добавляется. А добавление нод в дерево в Godot - это одна из самых затратных операций - не рекомендуется добавлять за один раз больше пары десятков нод, ибо дерево сцен работает в одном потоке, там много чего происходит.
Разделяй свой уровень на уникальные подсцены:
Даже если ты никогда не будешь использовать сцену "квартира" больше одного раза, имеет смысл хранить отдельно от "этажа" и "дома", чтоб тебе было удобнее редактировать и не нужно было лишний раз вкладки переключать. А для гигантских сцен типа "квартал" и "город" нужен свой собственный загрузчик по типу чанкового, с LODами и т.п. Базовый загрузчик Godot подходит только для небольших и средних сцен.
>Проблема - открытие этого уровня в редакторе, или переключение вкладок с уровня на что угодно и обратно, занимает секунд 5
Это нормально и ожидаемо.
Я не знаю точно, так как не изучал соответствующие исходники, но насколько я понимаю, всё, что видно в редакторе - это ноды, да, точно такие же, как у тебя в интерфейсе игры. При переключении вкладок старая сцена удаляется из дерева, а новая добавляется. А добавление нод в дерево в Godot - это одна из самых затратных операций - не рекомендуется добавлять за один раз больше пары десятков нод, ибо дерево сцен работает в одном потоке, там много чего происходит.
>при активной работе над ассетами приходится прыгать туда-сюда по вкладкам
Разделяй свой уровень на уникальные подсцены:
>город
>_ квартал
>_ _ дом
>_ _ _ этаж
>_ _ _ _ квартира
>_ _ _ _ _ комната
Даже если ты никогда не будешь использовать сцену "квартира" больше одного раза, имеет смысл хранить отдельно от "этажа" и "дома", чтоб тебе было удобнее редактировать и не нужно было лишний раз вкладки переключать. А для гигантских сцен типа "квартал" и "город" нужен свой собственный загрузчик по типу чанкового, с LODами и т.п. Базовый загрузчик Godot подходит только для небольших и средних сцен.
>>27858
Так подписывайся правильно и тестируй чаще. Ты же можешь запустить компонент отдельно от остальных.
То-то в GTA десятилетиями баги не фиксят...
Для 99% задач хватает _unhandled_input. Я бы сказал, постоянно запрашивать Input - это антипаттерн, с ним множество проблем в проекте сложнее "hello world". Обычный _input тоже редко нужен, юзай unhandled.
Это уже внутренняя кухня конкретного объекта. Мы обсуждаем внешнее взаимодействие объектов.
Это древняя концепция, на ней же построены RAD IDE наподобие Delphi и прочих. Веб в то время был в виде статичных текстов со ссылками без украшений. Вебу события не нужны в большинстве случаев, т.к. там stateless серверы, они отдают страничку и всё.
У тебя в любом случае менеджер будет, но благодаря событиям тебе легче с ним работать - т.к. он избегает необходимости копаться в том, что он там менеджит. События подключается к менеджеру, чтобы он знал о происходящих событиях у его подопечных объектов.
Ты так и не рассказал о "каскадном нарушении"...
>вид бага, неправильная подписка
Так подписывайся правильно и тестируй чаще. Ты же можешь запустить компонент отдельно от остальных.
>предпочитают чтобы был краш с логами
То-то в GTA десятилетиями баги не фиксят...
>Input.is_pressed(), Input.is_just_pressed()
Для 99% задач хватает _unhandled_input. Я бы сказал, постоянно запрашивать Input - это антипаттерн, с ним множество проблем в проекте сложнее "hello world". Обычный _input тоже редко нужен, юзай unhandled.
>Когда нажатие выставляет флаг, и он остается взведенным пока не будет считан.
Это уже внутренняя кухня конкретного объекта. Мы обсуждаем внешнее взаимодействие объектов.
>события притащены всякими веб макаками
Это древняя концепция, на ней же построены RAD IDE наподобие Delphi и прочих. Веб в то время был в виде статичных текстов со ссылками без украшений. Вебу события не нужны в большинстве случаев, т.к. там stateless серверы, они отдают страничку и всё.
>делай в нужных менеджерах
У тебя в любом случае менеджер будет, но благодаря событиям тебе легче с ним работать - т.к. он избегает необходимости копаться в том, что он там менеджит. События подключается к менеджеру, чтобы он знал о происходящих событиях у его подопечных объектов.
Ты так и не рассказал о "каскадном нарушении"...
>>27866
Я посмотрел в архиве:
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
Читай документацию в первую очередь.
>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
Читай документацию в первую очередь.
>>27865
У него же 3D игра, лол. Или ты про чанки?
Пара тысяч сцен - это нормально, если ты много чего копипастишь, типа коробок всяких. Предполагаю, он навалил декораций и теперь они долго загружаются. Поэтому переключается между мелкими сценами и громадной сценой. Нужно резать на чанки/комнаты.
Такое бывает, когда бросаешься делать Игру Мечты™ толком не разобравшись в своих инструментах и как обычно делаются проекты подобных масштабов.
Но, конечно, Godot тоже виноват, что вообще никак не предупреждает о таком ограничении/подвохе...
>спроектировать на тайлах
У него же 3D игра, лол. Или ты про чанки?
Пара тысяч сцен - это нормально, если ты много чего копипастишь, типа коробок всяких. Предполагаю, он навалил декораций и теперь они долго загружаются. Поэтому переключается между мелкими сценами и громадной сценой. Нужно резать на чанки/комнаты.
Такое бывает, когда бросаешься делать Игру Мечты™ толком не разобравшись в своих инструментах и как обычно делаются проекты подобных масштабов.
Но, конечно, Godot тоже виноват, что вообще никак не предупреждает о таком ограничении/подвохе...
>>27853
Ну я ебанул 3500 пустых MeshInstance3D и вижу то-же, что и у тебя, дело в редакторском SceneTree. При переключении память не осбождается почти но перестраивается дерево может он там сверяет трансформации ещё проходя по дереву. Я попрбовал прелоадом в реди тул скрипта добавлять эти 2 сцены но не помогло, не вижу какого-то выхода простого
Ну я ебанул 3500 пустых MeshInstance3D и вижу то-же, что и у тебя, дело в редакторском SceneTree. При переключении память не осбождается почти но перестраивается дерево может он там сверяет трансформации ещё проходя по дереву. Я попрбовал прелоадом в реди тул скрипта добавлять эти 2 сцены но не помогло, не вижу какого-то выхода простого
>>27884
Спасибо, анончик. Следующие уровни разобью на куски поменьше, чтобы лепить их легче было, а этот так доделаю.
Спасибо, анончик. Следующие уровни разобью на куски поменьше, чтобы лепить их легче было, а этот так доделаю.
>>27887
Неа, с ошибками все четко.
Неа, с ошибками все четко.
5 Кб, 261x137>>27886
Я мешинстанс заменил на Node3D, на пикче1 под каждой нодой 1500 нод и всё летает, ну у меня meshInstance получили ссылку в поле Skeleton и путь был не верный, сейчас вернулся и сделал кучу meshinstance пустых ~4000 , ну да секунд 5 переключает и не важно видимые или нет, какая-то внутрянка тормозит, в принципе на это можно бы создать issue
Я мешинстанс заменил на Node3D, на пикче1 под каждой нодой 1500 нод и всё летает, ну у меня meshInstance получили ссылку в поле Skeleton и путь был не верный, сейчас вернулся и сделал кучу meshinstance пустых ~4000 , ну да секунд 5 переключает и не важно видимые или нет, какая-то внутрянка тормозит, в принципе на это можно бы создать issue
126 Кб, 1209x404>>27891
В 4.4 было такое, на базе вот этого issue: https://github.com/godotengine/godot/issues/83460
Ты на какой версии проверял? Просто я вообще на тройке.
В 4.4 было такое, на базе вот этого issue: https://github.com/godotengine/godot/issues/83460
Ты на какой версии проверял? Просто я вообще на тройке.
>>27893
4.4.1
4.4.1
293 Кб, 604x453Посоны, помогите пожалуйста. У меня игра генерит при начальной загрузке с главного меню 400 карт шумов 512х512, которые в результате натягиваются на модельки в качестве текстур (упустим этот момент, я ебанутый, но так надо), что вызывает охуевше долгую загрузку где-то в 1.5 - 2 минуты по сути на простенькой, пусть и процедурно генерированной сцене. Куда мне слить эту генерацию, чтобы сократить время загрузки? Пробовал генерить прям во время появления объекта в кадре, но это вызывает неприятные, хотя и терпимые микрофризы. При необходимости я даже код скину, но там ничего интересного, просто генерация и запихивание в материал.
>>27893
Она ранее наверное ещё хуже работало, но в данном случае проблема с наследниками GeometryInstance3D и видимо их перерегистрацией на RenderingServer
Она ранее наверное ещё хуже работало, но в данном случае проблема с наследниками GeometryInstance3D и видимо их перерегистрацией на RenderingServer
>>27895
Сохрани свои шумы как файлы. Если рандомизация нужна наделай х5 от нужного и выбирай рандомный набор. Материалы с уже натянутыми текстурами тоже сохранить можно.
Сохрани свои шумы как файлы. Если рандомизация нужна наделай х5 от нужного и выбирай рандомный набор. Материалы с уже натянутыми текстурами тоже сохранить можно.
>>27897
Это вариант, но я пока склоняюсь к тому, что мне нужно прям огромное кол-во этих шумов. Но это, скорее спортивный интерес и если у меня ничего не получится, буду вынужден посохранять.
Это вариант, но я пока склоняюсь к тому, что мне нужно прям огромное кол-во этих шумов. Но это, скорее спортивный интерес и если у меня ничего не получится, буду вынужден посохранять.
>>27895
Ты б сначала замерил действитеольно ли генерация занимает большую часть времени или это создание материалов.
Ну и как оптимизацию делать генерацию можно в отдельном потоке.
Ты б сначала замерил действитеольно ли генерация занимает большую часть времени или это создание материалов.
Ну и как оптимизацию делать генерацию можно в отдельном потоке.
22 Кб, 562x562https://hipolink.net/godothread
Больше не актуален?
Зачем тогда его тащить из шапки в шапку, там вообще сдохший сайт висит.
Больше не актуален?
Зачем тогда его тащить из шапки в шапку, там вообще сдохший сайт висит.
>>27912
Юбка хороша, а шапка плоха.
Юбка хороша, а шапка плоха.
>>27912
Почему не актуален?!
Почему не актуален?!
>>27878
Тайлы для 3д называются GridMap, ими тоже можно расставлять коробки с коллайдерами. А если без коллайдеров и логики, то можно замутить MutliMesh Instance, есть аддоны для батчинга-склеивания/расклеивания на индивидуальные. Или можно сделать чтобы в редакторе виден мультимеш, а при загрузке на места инстансов грузились сцены с логикой. Этакий object pooling
Еще можно попробовать сохранить сцену в бинарном виде (.scn вместо .tscn), возможны риски, так что бэкапиться чаще.
Тайлы для 3д называются GridMap, ими тоже можно расставлять коробки с коллайдерами. А если без коллайдеров и логики, то можно замутить MutliMesh Instance, есть аддоны для батчинга-склеивания/расклеивания на индивидуальные. Или можно сделать чтобы в редакторе виден мультимеш, а при загрузке на места инстансов грузились сцены с логикой. Этакий object pooling
Еще можно попробовать сохранить сцену в бинарном виде (.scn вместо .tscn), возможны риски, так что бэкапиться чаще.
>>27895
Ограничься двумя картами шумов и например складывай их значения по какой то формуле (A[x,y] + B[x+id,y])
Вообще говоря, если разобраться в шуме, то можно создать одну карту побольше например 1024x1024 и выбирать разным объектам из нее разные квадраты, например с коориднат 96,48.
Или например есть 3d noise texture. Может быть она будет работать быстрее (а глубину использовать как индекс 2д среза шума).
Кроме того, может быть тебе вообще не надо создавать текстуры шума, а просто генерить его кодом в шейдере. Возможно в твоем случае это будет даже производительнее..
Ограничься двумя картами шумов и например складывай их значения по какой то формуле (A[x,y] + B[x+id,y])
Вообще говоря, если разобраться в шуме, то можно создать одну карту побольше например 1024x1024 и выбирать разным объектам из нее разные квадраты, например с коориднат 96,48.
Или например есть 3d noise texture. Может быть она будет работать быстрее (а глубину использовать как индекс 2д среза шума).
Кроме того, может быть тебе вообще не надо создавать текстуры шума, а просто генерить его кодом в шейдере. Возможно в твоем случае это будет даже производительнее..
>>27873
Открой любой 3д проект с контроллером персонажа, вот там в 99% будет Input.get_vector("left", "right", "up", "down")
>постоянно запрашивать Input - это антипаттерн, с ним множество проблем в проекте сложнее "hello world".
Открой любой 3д проект с контроллером персонажа, вот там в 99% будет Input.get_vector("left", "right", "up", "down")
>>27930
Нормальный если тебе обязтельно на русском, но учти что будут моменты что ты сделал всё один в один, а у тебя не работает, обычно надо дальше посмотреть или в комменты глянуть там бывают косяки описаны.
Нормальный если тебе обязтельно на русском, но учти что будут моменты что ты сделал всё один в один, а у тебя не работает, обычно надо дальше посмотреть или в комменты глянуть там бывают косяки описаны.
>>27930
Мультиплеерных?
Кстати, теперь я понял откуда знакомый мне скрины "своей" игры кидал. Вот из этого курса.
>7:09 создание кнопок
Мультиплеерных?
Кстати, теперь я понял откуда знакомый мне скрины "своей" игры кидал. Вот из этого курса.
60 Кб, 700x525>>27729
Команда разработки движка отказывается сделать в гдскрипте list comprehension, мотивируя это тем, что такой синтаксис "неудобочитаем". В результате я должен вместо элегантного
var item_descriptions = [item.description for item in items]
городить неуклюжий for на 3 строчки
Доколе?
Команда разработки движка отказывается сделать в гдскрипте list comprehension, мотивируя это тем, что такой синтаксис "неудобочитаем". В результате я должен вместо элегантного
var item_descriptions = [item.description for item in items]
городить неуклюжий for на 3 строчки
Доколе?
>>27972
Они мотивируют это тем, что:
- это нужно лишь <0.1% юзеров, т.е. НИНУЖНО;
- они не хотят поддерживать лишний сахар;
- есть filter(), map(), reduce(), any(), all().
https://docs.godotengine.org/en/stable/classes/class_array.html#class-array-method-map
Если я правильно понял, ты хочешь что-то такое:
На твоём месте я бы задумался, так ли уж нужно копипастить эти данные...
>мотивируя это тем, что такой синтаксис "неудобочитаем"
Они мотивируют это тем, что:
- это нужно лишь <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)
На твоём месте я бы задумался, так ли уж нужно копипастить эти данные...
>>27895
Если тебе обязательно нужно 400 уникальных шумов, и на каждый запуск игры они должны отличаться от предыдущих или меняться по каким-то правилам в реальном времени в процессе игры, то тут ничего не поделаешь - придётся ждать. Процедурная генерация редко используется в том числе из-за длительности запуска игры, что зачастую не оправдывается достоинствами процедурной генерации.
Если тебе достаточно 400 заранее созданных уникальных текстур, которые никак не меняются ни в процессе игры, ни после запуска новой игры, тогда логичным решением будет сохранить сгенерированный шум в PNG в папке проекта и затем заменить все NoiseTexture2D на ImageTexture. Можно автоматизировать процесс tool-скриптом. Так вместо генерации новой текстуры в рантайме из шума она будет считываться с диска.
Если тебе на самом деле хватило бы 1 текстуры шума, вставленной в 400 отдельных материалов, тогда сохрани один NoiseTexture2D в файл .tres и вставь этот файл во все материалы, которым нужен шум. Тогда шум будет сгенерирован один раз, на первом материале, а дальше будет использоваться ссылка на уже готовую текстуру (до тех пор, пока существует хотя бы один материал, использующий эту текстуру; если удалить все материалы, а потом снова добавить один, эта текстура перегенерируется с нуля).
Покажи хоть скриншот того, что ты там делаешь... Интересно же.
>400 карт шумов 512х512
Если тебе обязательно нужно 400 уникальных шумов, и на каждый запуск игры они должны отличаться от предыдущих или меняться по каким-то правилам в реальном времени в процессе игры, то тут ничего не поделаешь - придётся ждать. Процедурная генерация редко используется в том числе из-за длительности запуска игры, что зачастую не оправдывается достоинствами процедурной генерации.
Если тебе достаточно 400 заранее созданных уникальных текстур, которые никак не меняются ни в процессе игры, ни после запуска новой игры, тогда логичным решением будет сохранить сгенерированный шум в PNG в папке проекта и затем заменить все NoiseTexture2D на ImageTexture. Можно автоматизировать процесс tool-скриптом. Так вместо генерации новой текстуры в рантайме из шума она будет считываться с диска.
Если тебе на самом деле хватило бы 1 текстуры шума, вставленной в 400 отдельных материалов, тогда сохрани один NoiseTexture2D в файл .tres и вставь этот файл во все материалы, которым нужен шум. Тогда шум будет сгенерирован один раз, на первом материале, а дальше будет использоваться ссылка на уже готовую текстуру (до тех пор, пока существует хотя бы один материал, использующий эту текстуру; если удалить все материалы, а потом снова добавить один, эта текстура перегенерируется с нуля).
Покажи хоть скриншот того, что ты там делаешь... Интересно же.
>>27860
Не срут, а читают и отправляют сообщения. Не все, а те кому нужно.
Известно. Кто подписался, тот прочёл. Кто отписался, тот перестал читать. Кто желает испустить сигнал, тот вызвал эмит() на интересующем его сигнале.
Не тратят. Если ты подписан - ты реагируешь на испущенный сигнал, если не подписан, то ничего не фильтруешь. Если сигнал с данными (эмит(аргумент), то эти данные для тебя и для всех, кто подписался на сигнал. Если тебе из сигнала с данными приходится данные фильтровать - значит накосячил с архитектурой проекта.
У паттерна "event bus" есть свои минусы, но ты своим набросом не попал ни в один. Старайся лучше. Делай игры.
> в эту шину все срут
Не срут, а читают и отправляют сообщения. Не все, а те кому нужно.
> и неизвестно кто читает
Известно. Кто подписался, тот прочёл. Кто отписался, тот перестал читать. Кто желает испустить сигнал, тот вызвал эмит() на интересующем его сигнале.
> лишнюю производительность тратят на отфильтровывание того что не для них
Не тратят. Если ты подписан - ты реагируешь на испущенный сигнал, если не подписан, то ничего не фильтруешь. Если сигнал с данными (эмит(аргумент), то эти данные для тебя и для всех, кто подписался на сигнал. Если тебе из сигнала с данными приходится данные фильтровать - значит накосячил с архитектурой проекта.
У паттерна "event bus" есть свои минусы, но ты своим набросом не попал ни в один. Старайся лучше. Делай игры.
>>27978
Что будет если в одном из событий по неизвестной причине придут сериализованные данные с null? Как отследить отправителя и понять что привело к такому исходу? Или предлагаешь внедрять стектрейс в каждое чтобы не прогадать? Условно какой-то паджит сделал 0.000001f == 0.0000000004f и поле не присвоилось, а у события больше чем 1 отправитель. А что если прием сигнала вызывает в итоге отправку еще 1 сигнала и только там ты словишь исключение на null? Не говоря о том что каждое событие это аллокация и проверка типа этого события в самой шине. Гонка актуальности событий, из-за чего у людей происходит поражение/смерть после победы, потому что не учли, анон выше тоже про это писал. По мне так пусть лучше делают максимально без них, и оставят эту игрушку дьявола тем у кого реально есть ресурсы на юнит-тестирование и нанимание на работу людей понимающих эти ньюансы.
Что будет если в одном из событий по неизвестной причине придут сериализованные данные с null? Как отследить отправителя и понять что привело к такому исходу? Или предлагаешь внедрять стектрейс в каждое чтобы не прогадать? Условно какой-то паджит сделал 0.000001f == 0.0000000004f и поле не присвоилось, а у события больше чем 1 отправитель. А что если прием сигнала вызывает в итоге отправку еще 1 сигнала и только там ты словишь исключение на null? Не говоря о том что каждое событие это аллокация и проверка типа этого события в самой шине. Гонка актуальности событий, из-за чего у людей происходит поражение/смерть после победы, потому что не учли, анон выше тоже про это писал. По мне так пусть лучше делают максимально без них, и оставят эту игрушку дьявола тем у кого реально есть ресурсы на юнит-тестирование и нанимание на работу людей понимающих эти ньюансы.
>>27981
Анон выше смешал в кучу всё подряд. Если у тебя правильно написанная стейт-машина, то после того как она перешла в состояние победы, она уже не сможет перейти в состояние смерти, какие бы сигналы ей не прилетали бы по её подпискам.
В зависимости от требований и задач, подписанный на это событие агент проигнорирует это событие, либо сгенерирует данные по-умолчанию, либо вызовет событие уведомления об ошибке в пользовательском интерфейсе. Если проектируется многопоточная и/или распледеленная система - такие случаи учитываются на стадии проектирования.
Если твои паджиты работают не по твоему диздоку, не покрывают свой код тестами, а ты не проверяя платишь им деньги, то виноват не движок, ехехе.
> Гонка актуальности событий, из-за чего у людей происходит поражение/смерть после победы, потому что не учли, анон выше тоже про это писал.
Анон выше смешал в кучу всё подряд. Если у тебя правильно написанная стейт-машина, то после того как она перешла в состояние победы, она уже не сможет перейти в состояние смерти, какие бы сигналы ей не прилетали бы по её подпискам.
> Что будет если в одном из событий по неизвестной причине придут сериализованные данные с null?
В зависимости от требований и задач, подписанный на это событие агент проигнорирует это событие, либо сгенерирует данные по-умолчанию, либо вызовет событие уведомления об ошибке в пользовательском интерфейсе. Если проектируется многопоточная и/или распледеленная система - такие случаи учитываются на стадии проектирования.
> Условно какой-то паджит сделал
Если твои паджиты работают не по твоему диздоку, не покрывают свой код тестами, а ты не проверяя платишь им деньги, то виноват не движок, ехехе.
>>27987 (Del)
Игры делай, серун. Где твои игры?
Игры делай, серун. Где твои игры?
9,8 Мб, mp4,480x852, 1:07
https://www.youtube.com/watch?v=7i7BIWd5OK4&list=PLpp4UXjsd_VcEmblLEXiQ9W4h9I7V-X24
У того же русяз челика, новый курс по Годоту.
Игра на Годоте 4.3 с нуля.
У того же русяз челика, новый курс по Годоту.
Игра на Годоте 4.3 с нуля.
>>27998
Тем что его баги наконец зазернились в катарсисе и движок перестал ломаться на каждом релизе. Ну а еще там можно c# в вебе пилить
Тем что его баги наконец зазернились в катарсисе и движок перестал ломаться на каждом релизе. Ну а еще там можно c# в вебе пилить
>>28001
Ты чет попутал. В тройке опенсорсный моно, а дотнет так и вовсе под mit. Впрочем - кто его будет развивать если не ms - вопрос риторический, да, просто останется опенсорсный монолитный памятник.
Ты чет попутал. В тройке опенсорсный моно, а дотнет так и вовсе под mit. Впрочем - кто его будет развивать если не ms - вопрос риторический, да, просто останется опенсорсный монолитный памятник.
>>28001
Если не выискивать какие то дикие курьезные исключения, то ЯП (как лингвистическая сущность) не может кем то владеться или быть подкопирайтной. То есть никто не может тебе запретить сделать свой компилятор c#, со своим апи и либами. Вообще консенсунс такой что и апи и либы можно тоже юзать, по результатам суда гугл андроид vs oracle java В худшем случае запретят.использовать название c#, ну назоаегь СиХэш.
Если не выискивать какие то дикие курьезные исключения, то ЯП (как лингвистическая сущность) не может кем то владеться или быть подкопирайтной. То есть никто не может тебе запретить сделать свой компилятор c#, со своим апи и либами. Вообще консенсунс такой что и апи и либы можно тоже юзать, по результатам суда гугл андроид vs oracle java В худшем случае запретят.использовать название c#, ну назоаегь СиХэш.
>>28006
Смотри на суды Оракла с Гуглом из-за Андроида.
Естественно, это ЦРУ продавило решение в пользу Гугла, потому что это чисто их проект.
Кто будет заступаться за других?
Никто.
И тем более, если ваша компания - не из США.
Смотри на суды Оракла с Гуглом из-за Андроида.
Естественно, это ЦРУ продавило решение в пользу Гугла, потому что это чисто их проект.
Кто будет заступаться за других?
Никто.
И тем более, если ваша компания - не из США.
>>28005
Как же хочется отдельный от годота системный компилятор GDScript, если бы вы знали, но вы не знаете. Хочется консольные утилиты на нём писать. Хочется писать на нём оконные приложения. Хочется вот так:
> никто не может тебе запретить сделать свой компилятор
Как же хочется отдельный от годота системный компилятор GDScript, если бы вы знали, но вы не знаете. Хочется консольные утилиты на нём писать. Хочется писать на нём оконные приложения. Хочется вот так:
> class_name Program
> func main(args: Array[String]):
> > var app := Application.new()
> > app.run()
>>28011
Есть GNU аналог, Vala называется, он еще и задуман вроде чтобы в линуксе транспилироваться в быстрый C и без GC.
https://wiki.gnome.org/Projects/Vala/ValaForCSharpProgrammers
https://wiki.gnome.org/Projects/Vala/ValaForJavaProgrammers
Есть GNU аналог, Vala называется, он еще и задуман вроде чтобы в линуксе транспилироваться в быстрый C и без GC.
https://wiki.gnome.org/Projects/Vala/ValaForCSharpProgrammers
https://wiki.gnome.org/Projects/Vala/ValaForJavaProgrammers
>>28013
Так он базу говорит. C/C++ ок, там общественные комитеты создают стандарт. GDScript ок, он создан специально опенсорсным. А С# это третья нога.
Так он базу говорит. C/C++ ок, там общественные комитеты создают стандарт. GDScript ок, он создан специально опенсорсным. А С# это третья нога.
>>28011
А что будет когда придёт тролль и заявит патент на твое безпатентное спо? И скажет что любой продукт который содержит в составе это спо теперь должен ему ундециллион денег?
А что будет когда придёт тролль и заявит патент на твое безпатентное спо? И скажет что любой продукт который содержит в составе это спо теперь должен ему ундециллион денег?
>>28018
Мало того, майкрософт обещал не судиться по патентам с Моно и подобным, но что если наступит вендекапец, майкрософт разориться? И вот тут то патенты и выкупит какой то тролль, как уже бывало в истории.
Мало того, майкрософт обещал не судиться по патентам с Моно и подобным, но что если наступит вендекапец, майкрософт разориться? И вот тут то патенты и выкупит какой то тролль, как уже бывало в истории.
>>28020
Так он выкупит патенты только на реализацию по ecma шарп спицификации. Да, моно попадет под раздачу, но моно и так практически труп, по итогу просто нужно будет перенести с дотнета на что-то ещё.
Так он выкупит патенты только на реализацию по ecma шарп спицификации. Да, моно попадет под раздачу, но моно и так практически труп, по итогу просто нужно будет перенести с дотнета на что-то ещё.
>>28028
Я тоже делаю. Мне даёт. Но хочется системно. А щас делается прикладнО.
Я тоже делаю. Мне даёт. Но хочется системно. А щас делается прикладнО.
Он уже не знает какую хуйню вам забросить, а вы все ведетесь, пиздец. Через пару дней скажет вам что хочет гдскрипт в ядро линукса и что Хуан должен обеспечить, а раз нет, то кал.
>>27976 (Del)
Большинство не совсем слепые, а слабовидящие. С возрастом зрение обычно ухудшается. По опыту могу сказать, что красочные иллюстрации смотреть и с ослабленным зрением норм, а вот текст читать - это проблема. Лично я TTS не пользуюсь, но кому-то он наверняка полезен даже в играх. Minecraft вот даже реализовал TTS для чата... и субтитры для звуков. Во множестве игр текст настолько мелкий, что просто размазывается сглаживанием в нечитаемую кашу - поэтому ИИ скринридер не распознает символы.
Вообще, логика у тебя уровня:
А потом тебе будут негативные отзывы от AZERTY.
>особенно слепых
Большинство не совсем слепые, а слабовидящие. С возрастом зрение обычно ухудшается. По опыту могу сказать, что красочные иллюстрации смотреть и с ослабленным зрением норм, а вот текст читать - это проблема. Лично я TTS не пользуюсь, но кому-то он наверняка полезен даже в играх. Minecraft вот даже реализовал TTS для чата... и субтитры для звуков. Во множестве игр текст настолько мелкий, что просто размазывается сглаживанием в нечитаемую кашу - поэтому ИИ скринридер не распознает символы.
Вообще, логика у тебя уровня:
>Зачем делать биндинг клавиш? Мне и так норм.
А потом тебе будут негативные отзывы от AZERTY.
>>28012
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
Добавь папку с godot.exe в PATH, тогда сможешь из командной строки запускать скрипты как на питоне. Компилировать в принципе можно транспилером, но официальной поддержки пока нет (планируют).
Что-нибудь наподобие Godot Editor?
https://docs.godotengine.org/en/stable/classes/class_projectsettings.html#class-projectsettings-property-application-run-low-processor-mode
>Хочется консольные утилиты на нём писать.
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
46 Кб, 632x260Меня дико заебала вот эта мелкая залупа в тройке. Это та, которая связывает в юниформ все 3 значения Scale. Ставишь scale.x=10, y и z тоже становятся 10. В четверке она работает как нормальный человек - ее выключишь и она запомнит это, можно выключить ее на родителе и у всех детей она тоже выключится. А в тройке пиздец, она ничего не помнит, выключишь ее, скинешь селект с ноды, она включится обратно, сука.
Крч я заебался и решил выпатчить ее к хуям. Скачал исходники годота, 3 минуты найти грепом что закомментить, 2 минуты на сборку движка, и все.
И хочу сказать что я не ожидал что годот так легко патчится-билдится. Так и на гитхаб патч отправить не долго.
Крч я заебался и решил выпатчить ее к хуям. Скачал исходники годота, 3 минуты найти грепом что закомментить, 2 минуты на сборку движка, и все.
И хочу сказать что я не ожидал что годот так легко патчится-билдится. Так и на гитхаб патч отправить не долго.
Когда будет живой форк https://github.com/popcar2/GodotOS?
Этот сдох.
Этот сдох.
>>28046
Ну сдох и хуй с ним
Ну сдох и хуй с ним
пам
>>28039
Нормально, только я бы наверное не возился с пересборкой, а нашел ее плагинскриптом в окне, ведь окно годота это игра на годоте и можно искать прямо соответствующую ноду.
Нормально, только я бы наверное не возился с пересборкой, а нашел ее плагинскриптом в окне, ведь окно годота это игра на годоте и можно искать прямо соответствующую ноду.
>>28039
Звучит как правда, у меня 20 минут собирается, у тебя видимо суперкомпьютер
>2 минуты на сборку движка
Звучит как правда, у меня 20 минут собирается, у тебя видимо суперкомпьютер
>>28063
Да, я пытался сначала плагин написать, но не нашел ничего что можно было бы дернуть, чтобы убрать эту бесячую залупу. Вот бекпорт из 4.х в 3.6, может ты осилишь: https://github.com/godotengine/godot/pull/70185/files
Да, я пытался сначала плагин написать, но не нашел ничего что можно было бы дернуть, чтобы убрать эту бесячую залупу. Вот бекпорт из 4.х в 3.6, может ты осилишь: https://github.com/godotengine/godot/pull/70185/files
>>28039
Чё ты там неуниформно скейлишь, лол?
1. Текстуры раскорячит, даже трипланарные.
2. Физика вообще не дружит со скейлом.
3. Ноды-пустышки? Но зачем? ЗАЧЕМ?
Я стараюсь скейл не трогать вообще.
Алсо, не забывай об ошибках округления...
Потом ломаешь голову, почему не работает...
ОСОБЕННО если скейлишь ноды в цепочке.
Чё ты там неуниформно скейлишь, лол?
1. Текстуры раскорячит, даже трипланарные.
2. Физика вообще не дружит со скейлом.
3. Ноды-пустышки? Но зачем? ЗАЧЕМ?
Я стараюсь скейл не трогать вообще.
Алсо, не забывай об ошибках округления...
>print(scale)
>Vector3(1.0, 1.0, 1.000000000000000000069)
Потом ломаешь голову, почему не работает...
ОСОБЕННО если скейлишь ноды в цепочке.
>>28070
А я не отключаю связь масштабов. В физическом движке non uniform вроде не будет работать, а визуально я тоже нахапался раньше проблем, и пришел к подходу "честных исходных данных", если я хочу стену 1х2,5, то я меняю вершины, а не растягиваю куб 1х1, аналогично с модельками, фиксил как то кривую модельку приплюснув ее, словил каких то проблем то ли с анимацией то ли еще с чем, переделал в итоге в блендере на 1 к 1.
А я не отключаю связь масштабов. В физическом движке non uniform вроде не будет работать, а визуально я тоже нахапался раньше проблем, и пришел к подходу "честных исходных данных", если я хочу стену 1х2,5, то я меняю вершины, а не растягиваю куб 1х1, аналогично с модельками, фиксил как то кривую модельку приплюснув ее, словил каких то проблем то ли с анимацией то ли еще с чем, переделал в итоге в блендере на 1 к 1.
234 Кб, 930x771>>28080
>>28084
Да-да, расскажите как мне это нинужно, учитывая что визуальный scale mode даже в четверке до сих пор не юниформ и никого он не смущает. Тут у нас так, а тут иначе, а почему а вот потому что слышь тебе нинужно. Дело движка предупредить, а форсить меня в тот или иной воркфлоу не его дело.
Крч закоментил-перекомпилил и хуй с ним, без плагина обойдусь.
>>28084
Да-да, расскажите как мне это нинужно, учитывая что визуальный scale mode даже в четверке до сих пор не юниформ и никого он не смущает. Тут у нас так, а тут иначе, а почему а вот потому что слышь тебе нинужно. Дело движка предупредить, а форсить меня в тот или иной воркфлоу не его дело.
Крч закоментил-перекомпилил и хуй с ним, без плагина обойдусь.
>>27892 (Del)
>>27987 (Del)
Подумал-подумал и осознал, в чём твоя проблема. Ты привык писать код сверху вниз, засовывая максимум функций и логики на верхние уровни абстракции, т.е. условный скрипт game.gd, в котором у тебя 99% всего игрового кода работает. Если так - всё верно, тебе нет необходимости объявлять сигналы, ты просто всем руководишь сверху. Но это не всем подходит.
Альтернатива твоему подходу, которую продвигает философия Godot - это разработка снизу вверх, когда основные функции и логика находятся где-то внизу, в "листьях" дерева сцены, распределены между очень большим количеством скриптов и вложенных сцен. Поведение приложения не закладывается заранее, а проявляется эмерджентно, т.е. из взаимодействия множества никак не связанных компонентов.
Наглядный пример:
1. Сверху вниз: глобальный ИИ-дирижёр указывает бездумным пешкам, куда им идти, что делать; в ГТА глобальный ИИ-полицейский раздаёт всем юнитам местоположение игрока и требует его убить.
2. Снизу вверх: независимые ИИ-граждане решают локальные для них задачи автономно; в ГТА один полицейский с таким ИИ может проигнорировать пробегающего игрока, если он потерял рацию и не наблюдал лично совершение преступления.
В первом случае ты УЖЕ ЗНАЕШЬ, что делает каждая конкретная пешка, ведь у них у всех отсутствует своё собственное, индивидуальное поведение. Т.е. тебе совершенно не нужно слушать их сигналы.
Во втором случае по умолчанию ты ничего не знаешь, потому что каждый персонаж действует независимо. Однако, если ты хочешь организовать их, тебе всё же необходимо как-то передавать информацию одного персонажа остальным. Например, если ты хочешь оповестить всех полицейских, если один из них вдруг заметил игрока на месте преступления. Логичным и удобным будет добавить персонажу сигнал "замечен преступник", который вызывает сбор всех остальных полицейских к месту излучения сигнала.
Т.е. ты не понимаешь смысл сигналов/событий, т.к. используешь противоположный подход к разработке приложений. Если тебя удовлетворяет делать так, то никаких проблем нет. Но разработка сверху вниз как правило очень жёсткая и практически не допускает экспериментов, не обладает эмерджентностью.
Конечно, в реальной работе имеет смысл идти не полностью снизу вверх, а "изнутри наружу", т.е. из приблизительной середины вверх и вниз. Т.е. у тебя существует какая-то глобальная задумка, но ты ей оставляешь пространство для гибких манёвров. Т.е. персонаж сам по себе делается сверху вниз, а вот организация персонажей получается снизу вверх.
Короче говоря, если тебе не нужно - не пользуйся.
>профиты где?
>>27987 (Del)
>отлаживать как?
Подумал-подумал и осознал, в чём твоя проблема. Ты привык писать код сверху вниз, засовывая максимум функций и логики на верхние уровни абстракции, т.е. условный скрипт game.gd, в котором у тебя 99% всего игрового кода работает. Если так - всё верно, тебе нет необходимости объявлять сигналы, ты просто всем руководишь сверху. Но это не всем подходит.
Альтернатива твоему подходу, которую продвигает философия Godot - это разработка снизу вверх, когда основные функции и логика находятся где-то внизу, в "листьях" дерева сцены, распределены между очень большим количеством скриптов и вложенных сцен. Поведение приложения не закладывается заранее, а проявляется эмерджентно, т.е. из взаимодействия множества никак не связанных компонентов.
Наглядный пример:
1. Сверху вниз: глобальный ИИ-дирижёр указывает бездумным пешкам, куда им идти, что делать; в ГТА глобальный ИИ-полицейский раздаёт всем юнитам местоположение игрока и требует его убить.
2. Снизу вверх: независимые ИИ-граждане решают локальные для них задачи автономно; в ГТА один полицейский с таким ИИ может проигнорировать пробегающего игрока, если он потерял рацию и не наблюдал лично совершение преступления.
В первом случае ты УЖЕ ЗНАЕШЬ, что делает каждая конкретная пешка, ведь у них у всех отсутствует своё собственное, индивидуальное поведение. Т.е. тебе совершенно не нужно слушать их сигналы.
Во втором случае по умолчанию ты ничего не знаешь, потому что каждый персонаж действует независимо. Однако, если ты хочешь организовать их, тебе всё же необходимо как-то передавать информацию одного персонажа остальным. Например, если ты хочешь оповестить всех полицейских, если один из них вдруг заметил игрока на месте преступления. Логичным и удобным будет добавить персонажу сигнал "замечен преступник", который вызывает сбор всех остальных полицейских к месту излучения сигнала.
Т.е. ты не понимаешь смысл сигналов/событий, т.к. используешь противоположный подход к разработке приложений. Если тебя удовлетворяет делать так, то никаких проблем нет. Но разработка сверху вниз как правило очень жёсткая и практически не допускает экспериментов, не обладает эмерджентностью.
Конечно, в реальной работе имеет смысл идти не полностью снизу вверх, а "изнутри наружу", т.е. из приблизительной середины вверх и вниз. Т.е. у тебя существует какая-то глобальная задумка, но ты ей оставляешь пространство для гибких манёвров. Т.е. персонаж сам по себе делается сверху вниз, а вот организация персонажей получается снизу вверх.
Короче говоря, если тебе не нужно - не пользуйся.
>>27892 (Del)
>>27987 (Del)
Подумал-подумал и осознал, в чём твоя проблема. Ты привык писать код сверху вниз, засовывая максимум функций и логики на верхние уровни абстракции, т.е. условный скрипт game.gd, в котором у тебя 99% всего игрового кода работает. Если так - всё верно, тебе нет необходимости объявлять сигналы, ты просто всем руководишь сверху. Но это не всем подходит.
Альтернатива твоему подходу, которую продвигает философия Godot - это разработка снизу вверх, когда основные функции и логика находятся где-то внизу, в "листьях" дерева сцены, распределены между очень большим количеством скриптов и вложенных сцен. Поведение приложения не закладывается заранее, а проявляется эмерджентно, т.е. из взаимодействия множества никак не связанных компонентов.
Наглядный пример:
1. Сверху вниз: глобальный ИИ-дирижёр указывает бездумным пешкам, куда им идти, что делать; в ГТА глобальный ИИ-полицейский раздаёт всем юнитам местоположение игрока и требует его убить.
2. Снизу вверх: независимые ИИ-граждане решают локальные для них задачи автономно; в ГТА один полицейский с таким ИИ может проигнорировать пробегающего игрока, если он потерял рацию и не наблюдал лично совершение преступления.
В первом случае ты УЖЕ ЗНАЕШЬ, что делает каждая конкретная пешка, ведь у них у всех отсутствует своё собственное, индивидуальное поведение. Т.е. тебе совершенно не нужно слушать их сигналы.
Во втором случае по умолчанию ты ничего не знаешь, потому что каждый персонаж действует независимо. Однако, если ты хочешь организовать их, тебе всё же необходимо как-то передавать информацию одного персонажа остальным. Например, если ты хочешь оповестить всех полицейских, если один из них вдруг заметил игрока на месте преступления. Логичным и удобным будет добавить персонажу сигнал "замечен преступник", который вызывает сбор всех остальных полицейских к месту излучения сигнала.
Т.е. ты не понимаешь смысл сигналов/событий, т.к. используешь противоположный подход к разработке приложений. Если тебя удовлетворяет делать так, то никаких проблем нет. Но разработка сверху вниз как правило очень жёсткая и практически не допускает экспериментов, не обладает эмерджентностью.
Конечно, в реальной работе имеет смысл идти не полностью снизу вверх, а "изнутри наружу", т.е. из приблизительной середины вверх и вниз. Т.е. у тебя существует какая-то глобальная задумка, но ты ей оставляешь пространство для гибких манёвров. Т.е. персонаж сам по себе делается сверху вниз, а вот организация персонажей получается снизу вверх.
Короче говоря, если тебе не нужно - не пользуйся.
>профиты где?
>>27987 (Del)
>отлаживать как?
Подумал-подумал и осознал, в чём твоя проблема. Ты привык писать код сверху вниз, засовывая максимум функций и логики на верхние уровни абстракции, т.е. условный скрипт game.gd, в котором у тебя 99% всего игрового кода работает. Если так - всё верно, тебе нет необходимости объявлять сигналы, ты просто всем руководишь сверху. Но это не всем подходит.
Альтернатива твоему подходу, которую продвигает философия Godot - это разработка снизу вверх, когда основные функции и логика находятся где-то внизу, в "листьях" дерева сцены, распределены между очень большим количеством скриптов и вложенных сцен. Поведение приложения не закладывается заранее, а проявляется эмерджентно, т.е. из взаимодействия множества никак не связанных компонентов.
Наглядный пример:
1. Сверху вниз: глобальный ИИ-дирижёр указывает бездумным пешкам, куда им идти, что делать; в ГТА глобальный ИИ-полицейский раздаёт всем юнитам местоположение игрока и требует его убить.
2. Снизу вверх: независимые ИИ-граждане решают локальные для них задачи автономно; в ГТА один полицейский с таким ИИ может проигнорировать пробегающего игрока, если он потерял рацию и не наблюдал лично совершение преступления.
В первом случае ты УЖЕ ЗНАЕШЬ, что делает каждая конкретная пешка, ведь у них у всех отсутствует своё собственное, индивидуальное поведение. Т.е. тебе совершенно не нужно слушать их сигналы.
Во втором случае по умолчанию ты ничего не знаешь, потому что каждый персонаж действует независимо. Однако, если ты хочешь организовать их, тебе всё же необходимо как-то передавать информацию одного персонажа остальным. Например, если ты хочешь оповестить всех полицейских, если один из них вдруг заметил игрока на месте преступления. Логичным и удобным будет добавить персонажу сигнал "замечен преступник", который вызывает сбор всех остальных полицейских к месту излучения сигнала.
Т.е. ты не понимаешь смысл сигналов/событий, т.к. используешь противоположный подход к разработке приложений. Если тебя удовлетворяет делать так, то никаких проблем нет. Но разработка сверху вниз как правило очень жёсткая и практически не допускает экспериментов, не обладает эмерджентностью.
Конечно, в реальной работе имеет смысл идти не полностью снизу вверх, а "изнутри наружу", т.е. из приблизительной середины вверх и вниз. Т.е. у тебя существует какая-то глобальная задумка, но ты ей оставляешь пространство для гибких манёвров. Т.е. персонаж сам по себе делается сверху вниз, а вот организация персонажей получается снизу вверх.
Короче говоря, если тебе не нужно - не пользуйся.
>>28102
А я так и делаю.
А я так и делаю.
>>27974
То что ты предлагаешь это анонимные функции. Понимаю что ими тоже можно, но согласись что такие конструкции считываются глазом куда хуже, да и beginner-friendly такую математику не назовёшь
То что ты предлагаешь это анонимные функции. Понимаю что ими тоже можно, но согласись что такие конструкции считываются глазом куда хуже, да и beginner-friendly такую математику не назовёшь
>>28167
Не соглашусь. Вполне читаемо. Особенно новичку, потому что мне, старичку паскаля, наоборот было труднее принять для себя тот факт, что определения функции можно пихать в аргументы других функций. Именно новичку глубоко поебать, где объявлена функция, у него нет детской травмы насчёт того что функция когда-то 40 лет была фундаментальным закостеневшим элементом синтаксиса и дизайна.
> согласись что такие конструкции считываются глазом куда хуже, да и beginner-friendly такую математику не назовёшь
Не соглашусь. Вполне читаемо. Особенно новичку, потому что мне, старичку паскаля, наоборот было труднее принять для себя тот факт, что определения функции можно пихать в аргументы других функций. Именно новичку глубоко поебать, где объявлена функция, у него нет детской травмы насчёт того что функция когда-то 40 лет была фундаментальным закостеневшим элементом синтаксиса и дизайна.
>>28183
Ты ошибаешься. Всякие лямбды сложно считываются новичками. Они вообще функции не любят. А вот операторы воспринимают спокойно.
им больше по душе print 'hello world', чем print('hello world')
и предпочитают a,b,c = [a,b,c,d,e][0:3] вместо того что ты там дал в качестве примера
>Именно новичку глубоко поебать, где объявлена функция, у него нет детской травмы
Ты ошибаешься. Всякие лямбды сложно считываются новичками. Они вообще функции не любят. А вот операторы воспринимают спокойно.
им больше по душе print 'hello world', чем print('hello world')
и предпочитают a,b,c = [a,b,c,d,e][0:3] вместо того что ты там дал в качестве примера
>>28189
Не согласен. Новички не видят разницы между оператором и замыканием. Замыкание для новичка - это такая разновидность оператора.
Что я там дал? С подливой?
Не согласен. Новички не видят разницы между оператором и замыканием. Замыкание для новичка - это такая разновидность оператора.
> вместо того что ты там дал в качестве примера
Что я там дал? С подливой?
>>28167
Функциональный подход, т.е. основа питона.
>>28183
Не, это как раз легко принять. Что трудно принять - отсутствие ВЛОЖЕННЫХ функций внутри других. Для примера, почему GDScript не позволяет сделать так?
Это крайне полезно на Pascal, почему здесь нет? Т.е. приходится зря захламлять общее поле видимости локально изолированными функциями. Обидно.
>>28189
Пускай привыкают, дробление на функции - база.
Херня какая-то нечитаемая, лучше уж так:
ОДНАКО, если ты хочешь разделить массив на набор именованных переменных, ты уже где-то накосячил и необходимо рефакторингом заниматься.
Помни: у переменных в массивах нет личных имён; в массивах однородные данные с общим именем. Если посмотреть на Array в GDScript, может показаться, что массивы могут содержать что угодно (Variant), но тебе следует избегать сваливать в кучу разные данные.
Ассоциативные массивы (Dictionary) - другое дело.
>То что ты предлагаешь это
Функциональный подход, т.е. основа питона.
>>28183
>мне, старичку паскаля, наоборот было труднее принять для себя тот факт, что определения функции можно пихать в аргументы других функций
Не, это как раз легко принять. Что трудно принять - отсутствие ВЛОЖЕННЫХ функций внутри других. Для примера, почему 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, почему здесь нет? Т.е. приходится зря захламлять общее поле видимости локально изолированными функциями. Обидно.
>>28189
>Они вообще функции не любят
Пускай привыкают, дробление на функции - база.
>предпочитают a,b,c = [a,b,c,d,e][0:3]
Херня какая-то нечитаемая, лучше уж так:
>a = arr[0]; b = arr[1]; c = arr[3]
ОДНАКО, если ты хочешь разделить массив на набор именованных переменных, ты уже где-то накосячил и необходимо рефакторингом заниматься.
Помни: у переменных в массивах нет личных имён; в массивах однородные данные с общим именем. Если посмотреть на Array в GDScript, может показаться, что массивы могут содержать что угодно (Variant), но тебе следует избегать сваливать в кучу разные данные.
Ассоциативные массивы (Dictionary) - другое дело.
>>28167
Функциональный подход, т.е. основа питона.
>>28183
Не, это как раз легко принять. Что трудно принять - отсутствие ВЛОЖЕННЫХ функций внутри других. Для примера, почему GDScript не позволяет сделать так?
Это крайне полезно на Pascal, почему здесь нет? Т.е. приходится зря захламлять общее поле видимости локально изолированными функциями. Обидно.
>>28189
Пускай привыкают, дробление на функции - база.
Херня какая-то нечитаемая, лучше уж так:
ОДНАКО, если ты хочешь разделить массив на набор именованных переменных, ты уже где-то накосячил и необходимо рефакторингом заниматься.
Помни: у переменных в массивах нет личных имён; в массивах однородные данные с общим именем. Если посмотреть на Array в GDScript, может показаться, что массивы могут содержать что угодно (Variant), но тебе следует избегать сваливать в кучу разные данные.
Ассоциативные массивы (Dictionary) - другое дело.
>То что ты предлагаешь это
Функциональный подход, т.е. основа питона.
>>28183
>мне, старичку паскаля, наоборот было труднее принять для себя тот факт, что определения функции можно пихать в аргументы других функций
Не, это как раз легко принять. Что трудно принять - отсутствие ВЛОЖЕННЫХ функций внутри других. Для примера, почему 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, почему здесь нет? Т.е. приходится зря захламлять общее поле видимости локально изолированными функциями. Обидно.
>>28189
>Они вообще функции не любят
Пускай привыкают, дробление на функции - база.
>предпочитают a,b,c = [a,b,c,d,e][0:3]
Херня какая-то нечитаемая, лучше уж так:
>a = arr[0]; b = arr[1]; c = arr[3]
ОДНАКО, если ты хочешь разделить массив на набор именованных переменных, ты уже где-то накосячил и необходимо рефакторингом заниматься.
Помни: у переменных в массивах нет личных имён; в массивах однородные данные с общим именем. Если посмотреть на Array в GDScript, может показаться, что массивы могут содержать что угодно (Variant), но тебе следует избегать сваливать в кучу разные данные.
Ассоциативные массивы (Dictionary) - другое дело.
32 Кб, 450x273>>28221
> Т.е. приходится зря захламлять общее поле видимости локально изолированными функциями. Обидно.
>>28230
Интересно, интерпретатор GDScript оптимизирует это? Потому что выглядит как парсинг + присваивание на каждый вызов, что явно плохо. Компилируемый ЯП, очевидно, скомпилирует всё как надо, а с GDScript на данном этапе непонятно что получится.
Можно протестировать, вызвав 10.000 раз в цикле с разными вариантами. Скорее всего будет медленнее обычного объявления функций в скрипте.
>>28232
Циферки поставил чисто для лучшей читаемости. Технически они, конечно, не нужны.
Интересно, интерпретатор GDScript оптимизирует это? Потому что выглядит как парсинг + присваивание на каждый вызов, что явно плохо. Компилируемый ЯП, очевидно, скомпилирует всё как надо, а с GDScript на данном этапе непонятно что получится.
Можно протестировать, вызвав 10.000 раз в цикле с разными вариантами. Скорее всего будет медленнее обычного объявления функций в скрипте.
>>28232
Циферки поставил чисто для лучшей читаемости. Технически они, конечно, не нужны.
>>28115 (Del)
Но ведь эта гибкость достигается на событиях. Без событийности у тебя будет постоянное связывание в неожиданных местах, которые трудно отследить и приходится доверять компилятору (который тупит).
Архитектура на событиях подобна конструктору Лего: кирпичики независимы и тривиально соединяются в желаемую конструкцию, и так же легко разделяются.
Эта сложность на 99% зависит от хотелок. Если ты пытаешься разработать ММО экшн РПГ с физикой и симуляцией экосистем в космосе, тогда ты с любой архитектурой зафейлишься. А обычный платформер разработать проще на архитектуре с событиями.
И сразу описываешь архитектуру сверху вниз:
Если у тебя не "сверху вниз", у тебя нет управляющего (изначально по крайней мере; позже его доделаешь). Попробуй добавить свою пешку на пустую сцену и запустить - что заработает, а что не заработает?
Т.е. ты делаешь сверху вниз и не осознаёшь этого. По крайней мере описываешь всю систему сверху вниз.
"Шину событий" предложил другой анон. Лично я (мои сообщения тут самые длинные, лол) против создания глобальной "шины событий", ибо это тупо синглтон. А синглтоны чаще вредят, чем приносят пользу.
Я рекомендую использовать события локально - т.е. излучатели сигналов сидят рядом с получателями. В сложных случаях делаешь релейную систему, чтобы избежать лишнего связывания независимых систем. Ошибки легко локализуются, т.к. если у тебя что-то сломалось, ты уже знаешь, где оно сломалось. Код не размазан по всему проекту, а чётко собран.
Да, я согласен, что кода (строчек и файлов) в целом получается больше. Но это не проблема. Проблема - отсутствие гибкости на стадии хаотичных изменений, которая самая важная в разработке игры. Кто-то ECS рекомендует, а я рекомендую ООП с событиями, оба варианта по-разному решают одну проблему в коде (избыточное связывание независимых систем).
Речь не об объектах в коде, а о геймдизайне. Ты УЖЕ ЗНАЕШЬ (как человек), что твои NPC обязаны будут разыгрывать в игровом мире, и соответственно тупо приказываешь им сверху вниз. Это логично для игр наподобие ААА кинца-мыльца, но если твой план не идеален, переигрывать всё будет очень сложно, т.к. изначально не планировалось делать как-то иначе.
Если делать снизу вверх, ты делаешь NPC, которые теоретически могут играть любую роль в любом, не запланированном изначально сценарии. Для этого требуется, чтоб они существовали независимо, как самостоятельные программы, которым можно дать приказы, но которые действуют сами по себе. Без использования событий ты не знаешь, что там у них происходит (либо залез внутрь и дёргаешь кишки).
Godot просто даёт удобный инструмент, чтобы ты не изобретал велосипед ради решения этой задачи...
...а, так ты у нас изобретатель велосипедов, лол.
Мне ECS не нравится из-за слабого зацепления. Т.е. связность снижается, но сцеплять код становится значительно сложнее, чем в классическом ООП. Это называется, вроде, деструктивным развязыванием. Отсутствуют конкретные объекты, всё лежит в виде развалившихся по разным "системам" потрохов.
Понимаю, если ты хочешь делать игру независимо от игрового движка. Но на мой взгляд, это избыточная абстракция для 99.9% разработчиков игр. Во-первых, большинство игр никогда не увидят свет. Во-вторых, переписать на другой инструмент проще, чем что-то изобретать с нуля. В-третьих, альтернатив Godot не существует пока и вряд ли что-то скоро появится (проприетарные движки вообще не рассматриваю).
>достаточно гибкая архитектурная абстракция
Но ведь эта гибкость достигается на событиях. Без событийности у тебя будет постоянное связывание в неожиданных местах, которые трудно отследить и приходится доверять компилятору (который тупит).
Архитектура на событиях подобна конструктору Лего: кирпичики независимы и тривиально соединяются в желаемую конструкцию, и так же легко разделяются.
>градации сложности кодовой базы которую один человек может потянуть, а какую не может потянуть, либо может но с большими трудностями
Эта сложность на 99% зависит от хотелок. Если ты пытаешься разработать ММО экшн РПГ с физикой и симуляцией экосистем в космосе, тогда ты с любой архитектурой зафейлишься. А обычный платформер разработать проще на архитектуре с событиями.
>Я бы так не стал делать...
И сразу описываешь архитектуру сверху вниз:
>...фабрика пешки возвратит ее (синглтону/более высокому управляющему звену) конвееру NPC глобального мира...
Если у тебя не "сверху вниз", у тебя нет управляющего (изначально по крайней мере; позже его доделаешь). Попробуй добавить свою пешку на пустую сцену и запустить - что заработает, а что не заработает?
Т.е. ты делаешь сверху вниз и не осознаёшь этого. По крайней мере описываешь всю систему сверху вниз.
>в отличии от шины событий
"Шину событий" предложил другой анон. Лично я (мои сообщения тут самые длинные, лол) против создания глобальной "шины событий", ибо это тупо синглтон. А синглтоны чаще вредят, чем приносят пользу.
Я рекомендую использовать события локально - т.е. излучатели сигналов сидят рядом с получателями. В сложных случаях делаешь релейную систему, чтобы избежать лишнего связывания независимых систем. Ошибки легко локализуются, т.к. если у тебя что-то сломалось, ты уже знаешь, где оно сломалось. Код не размазан по всему проекту, а чётко собран.
Да, я согласен, что кода (строчек и файлов) в целом получается больше. Но это не проблема. Проблема - отсутствие гибкости на стадии хаотичных изменений, которая самая важная в разработке игры. Кто-то ECS рекомендует, а я рекомендую ООП с событиями, оба варианта по-разному решают одну проблему в коде (избыточное связывание независимых систем).
>>В первом случае ты УЖЕ ЗНАЕШЬ
>Нет, не знаю. Год обжекты зло
Речь не об объектах в коде, а о геймдизайне. Ты УЖЕ ЗНАЕШЬ (как человек), что твои NPC обязаны будут разыгрывать в игровом мире, и соответственно тупо приказываешь им сверху вниз. Это логично для игр наподобие ААА кинца-мыльца, но если твой план не идеален, переигрывать всё будет очень сложно, т.к. изначально не планировалось делать как-то иначе.
Если делать снизу вверх, ты делаешь NPC, которые теоретически могут играть любую роль в любом, не запланированном изначально сценарии. Для этого требуется, чтоб они существовали независимо, как самостоятельные программы, которым можно дать приказы, но которые действуют сами по себе. Без использования событий ты не знаешь, что там у них происходит (либо залез внутрь и дёргаешь кишки).
Godot просто даёт удобный инструмент, чтобы ты не изобретал велосипед ради решения этой задачи...
>пересел на собственный ecs-like фреймворк
...а, так ты у нас изобретатель велосипедов, лол.
Мне ECS не нравится из-за слабого зацепления. Т.е. связность снижается, но сцеплять код становится значительно сложнее, чем в классическом ООП. Это называется, вроде, деструктивным развязыванием. Отсутствуют конкретные объекты, всё лежит в виде развалившихся по разным "системам" потрохов.
Понимаю, если ты хочешь делать игру независимо от игрового движка. Но на мой взгляд, это избыточная абстракция для 99.9% разработчиков игр. Во-первых, большинство игр никогда не увидят свет. Во-вторых, переписать на другой инструмент проще, чем что-то изобретать с нуля. В-третьих, альтернатив Godot не существует пока и вряд ли что-то скоро появится (проприетарные движки вообще не рассматриваю).
>>28115 (Del)
Но ведь эта гибкость достигается на событиях. Без событийности у тебя будет постоянное связывание в неожиданных местах, которые трудно отследить и приходится доверять компилятору (который тупит).
Архитектура на событиях подобна конструктору Лего: кирпичики независимы и тривиально соединяются в желаемую конструкцию, и так же легко разделяются.
Эта сложность на 99% зависит от хотелок. Если ты пытаешься разработать ММО экшн РПГ с физикой и симуляцией экосистем в космосе, тогда ты с любой архитектурой зафейлишься. А обычный платформер разработать проще на архитектуре с событиями.
И сразу описываешь архитектуру сверху вниз:
Если у тебя не "сверху вниз", у тебя нет управляющего (изначально по крайней мере; позже его доделаешь). Попробуй добавить свою пешку на пустую сцену и запустить - что заработает, а что не заработает?
Т.е. ты делаешь сверху вниз и не осознаёшь этого. По крайней мере описываешь всю систему сверху вниз.
"Шину событий" предложил другой анон. Лично я (мои сообщения тут самые длинные, лол) против создания глобальной "шины событий", ибо это тупо синглтон. А синглтоны чаще вредят, чем приносят пользу.
Я рекомендую использовать события локально - т.е. излучатели сигналов сидят рядом с получателями. В сложных случаях делаешь релейную систему, чтобы избежать лишнего связывания независимых систем. Ошибки легко локализуются, т.к. если у тебя что-то сломалось, ты уже знаешь, где оно сломалось. Код не размазан по всему проекту, а чётко собран.
Да, я согласен, что кода (строчек и файлов) в целом получается больше. Но это не проблема. Проблема - отсутствие гибкости на стадии хаотичных изменений, которая самая важная в разработке игры. Кто-то ECS рекомендует, а я рекомендую ООП с событиями, оба варианта по-разному решают одну проблему в коде (избыточное связывание независимых систем).
Речь не об объектах в коде, а о геймдизайне. Ты УЖЕ ЗНАЕШЬ (как человек), что твои NPC обязаны будут разыгрывать в игровом мире, и соответственно тупо приказываешь им сверху вниз. Это логично для игр наподобие ААА кинца-мыльца, но если твой план не идеален, переигрывать всё будет очень сложно, т.к. изначально не планировалось делать как-то иначе.
Если делать снизу вверх, ты делаешь NPC, которые теоретически могут играть любую роль в любом, не запланированном изначально сценарии. Для этого требуется, чтоб они существовали независимо, как самостоятельные программы, которым можно дать приказы, но которые действуют сами по себе. Без использования событий ты не знаешь, что там у них происходит (либо залез внутрь и дёргаешь кишки).
Godot просто даёт удобный инструмент, чтобы ты не изобретал велосипед ради решения этой задачи...
...а, так ты у нас изобретатель велосипедов, лол.
Мне ECS не нравится из-за слабого зацепления. Т.е. связность снижается, но сцеплять код становится значительно сложнее, чем в классическом ООП. Это называется, вроде, деструктивным развязыванием. Отсутствуют конкретные объекты, всё лежит в виде развалившихся по разным "системам" потрохов.
Понимаю, если ты хочешь делать игру независимо от игрового движка. Но на мой взгляд, это избыточная абстракция для 99.9% разработчиков игр. Во-первых, большинство игр никогда не увидят свет. Во-вторых, переписать на другой инструмент проще, чем что-то изобретать с нуля. В-третьих, альтернатив Godot не существует пока и вряд ли что-то скоро появится (проприетарные движки вообще не рассматриваю).
>достаточно гибкая архитектурная абстракция
Но ведь эта гибкость достигается на событиях. Без событийности у тебя будет постоянное связывание в неожиданных местах, которые трудно отследить и приходится доверять компилятору (который тупит).
Архитектура на событиях подобна конструктору Лего: кирпичики независимы и тривиально соединяются в желаемую конструкцию, и так же легко разделяются.
>градации сложности кодовой базы которую один человек может потянуть, а какую не может потянуть, либо может но с большими трудностями
Эта сложность на 99% зависит от хотелок. Если ты пытаешься разработать ММО экшн РПГ с физикой и симуляцией экосистем в космосе, тогда ты с любой архитектурой зафейлишься. А обычный платформер разработать проще на архитектуре с событиями.
>Я бы так не стал делать...
И сразу описываешь архитектуру сверху вниз:
>...фабрика пешки возвратит ее (синглтону/более высокому управляющему звену) конвееру NPC глобального мира...
Если у тебя не "сверху вниз", у тебя нет управляющего (изначально по крайней мере; позже его доделаешь). Попробуй добавить свою пешку на пустую сцену и запустить - что заработает, а что не заработает?
Т.е. ты делаешь сверху вниз и не осознаёшь этого. По крайней мере описываешь всю систему сверху вниз.
>в отличии от шины событий
"Шину событий" предложил другой анон. Лично я (мои сообщения тут самые длинные, лол) против создания глобальной "шины событий", ибо это тупо синглтон. А синглтоны чаще вредят, чем приносят пользу.
Я рекомендую использовать события локально - т.е. излучатели сигналов сидят рядом с получателями. В сложных случаях делаешь релейную систему, чтобы избежать лишнего связывания независимых систем. Ошибки легко локализуются, т.к. если у тебя что-то сломалось, ты уже знаешь, где оно сломалось. Код не размазан по всему проекту, а чётко собран.
Да, я согласен, что кода (строчек и файлов) в целом получается больше. Но это не проблема. Проблема - отсутствие гибкости на стадии хаотичных изменений, которая самая важная в разработке игры. Кто-то ECS рекомендует, а я рекомендую ООП с событиями, оба варианта по-разному решают одну проблему в коде (избыточное связывание независимых систем).
>>В первом случае ты УЖЕ ЗНАЕШЬ
>Нет, не знаю. Год обжекты зло
Речь не об объектах в коде, а о геймдизайне. Ты УЖЕ ЗНАЕШЬ (как человек), что твои NPC обязаны будут разыгрывать в игровом мире, и соответственно тупо приказываешь им сверху вниз. Это логично для игр наподобие ААА кинца-мыльца, но если твой план не идеален, переигрывать всё будет очень сложно, т.к. изначально не планировалось делать как-то иначе.
Если делать снизу вверх, ты делаешь NPC, которые теоретически могут играть любую роль в любом, не запланированном изначально сценарии. Для этого требуется, чтоб они существовали независимо, как самостоятельные программы, которым можно дать приказы, но которые действуют сами по себе. Без использования событий ты не знаешь, что там у них происходит (либо залез внутрь и дёргаешь кишки).
Godot просто даёт удобный инструмент, чтобы ты не изобретал велосипед ради решения этой задачи...
>пересел на собственный ecs-like фреймворк
...а, так ты у нас изобретатель велосипедов, лол.
Мне ECS не нравится из-за слабого зацепления. Т.е. связность снижается, но сцеплять код становится значительно сложнее, чем в классическом ООП. Это называется, вроде, деструктивным развязыванием. Отсутствуют конкретные объекты, всё лежит в виде развалившихся по разным "системам" потрохов.
Понимаю, если ты хочешь делать игру независимо от игрового движка. Но на мой взгляд, это избыточная абстракция для 99.9% разработчиков игр. Во-первых, большинство игр никогда не увидят свет. Во-вторых, переписать на другой инструмент проще, чем что-то изобретать с нуля. В-третьих, альтернатив Godot не существует пока и вряд ли что-то скоро появится (проприетарные движки вообще не рассматриваю).
>>28236
Некоторые паттерны - это тупо переименованный синглтон. Потому что синглтоношизики вконец охуели. Например, паттерн обсервер - это тупо синглтон. Паттерн менеджер - это тупо синглтон. Процессор - синглтон. Свердловск - синглтон.
> "Шину событий" предложил другой анон. Лично я (мои сообщения тут самые длинные, лол) против создания глобальной "шины событий", ибо это тупо синглтон. А синглтоны чаще вредят, чем приносят пользу.
Некоторые паттерны - это тупо переименованный синглтон. Потому что синглтоношизики вконец охуели. Например, паттерн обсервер - это тупо синглтон. Паттерн менеджер - это тупо синглтон. Процессор - синглтон. Свердловск - синглтон.
>>28243
Процессор - уже не синглтон, с тех пор как появился Intel Adler Lake. С парой мощных ядер и четверкой экономичных урезанных. Как можно догадаться, сингтоношизики (которые считали процессор одним синглтоном) грустно пошли переписывать софт, ведь они полагали что ядро всегда одинаковое, неважно на какое попадет поток.
Процессор - уже не синглтон, с тех пор как появился Intel Adler Lake. С парой мощных ядер и четверкой экономичных урезанных. Как можно догадаться, сингтоношизики (которые считали процессор одним синглтоном) грустно пошли переписывать софт, ведь они полагали что ядро всегда одинаковое, неважно на какое попадет поток.
>>28263
Ты это синглтон. Как нам переписать тебя под кнопочно-мультиплеерную архитектуру?
Ты это синглтон. Как нам переписать тебя под кнопочно-мультиплеерную архитектуру?
Помните жируху комьюнити менеджера, из-за которой развезли драму с вокотом? Она все. А вместе с ней, видимо, упразднили и позицию комьюнити менеджера. Уже полгода как замечаю что все новости/блоги годота пишут технари, а никакие не менеджеры. Как, кстати, и было до нее.
>>28326
Какой то срачер пытался накидывать, но его все просто скрывали. Он так и ушел грустным.
Какой то срачер пытался накидывать, но его все просто скрывали. Он так и ушел грустным.
Ебаный скоп
398 Кб, 1280x960Хочу навайбкодить какой-нибудь очередной 2д-платформерошутан в пиксельном стиле.
Годот хорошо подходит для такого? Ну по сравнению например с УЕ?
Годот хорошо подходит для такого? Ну по сравнению например с УЕ?
>>28496 (Del)
Лови свой репорт.
Лови свой репорт.
>>28499
Я не он, но за что репорт?
Я не он, но за что репорт?
>>28496 (Del)
Жирный жирный поезд пассажирный
Жирный жирный поезд пассажирный
Поясните, это правда что он тут написал >>28510 (Del)
?
?
>>28513
Кто? Где? Пост не найден.
Кто? Где? Пост не найден.
Чего тут, залетные юнитупари как всегда тупят? Ничего нового. Прорепортил чухана с его роялти за скачивания.
>>28513
Это движкосрачер подосрать пытается.
Проблемы у Godot есть, но совсем другие.
>>28510 (Del)
Ты так жалуешься, будто ассетфлипер какой.
Покажи свою лучшую игру (на любом движке).
>>28496 (Del)
Не советую - слишком много подводных камней.
>>28495
Зачем вайбкодить, есть же готовый код на гитхабе.
https://github.com/SlayHorizon/godot-2d-platformer-demo
Рисовать кто будет? Базовые нейронки не умеют.
Годот-то подходит, но хватит ли тебе усидчивости?
С какой целью в геймдев вкатываешься? Деньги?
Это движкосрачер подосрать пытается.
Проблемы у Godot есть, но совсем другие.
>>28510 (Del)
Ты так жалуешься, будто ассетфлипер какой.
Покажи свою лучшую игру (на любом движке).
>>28496 (Del)
>бери юнити
Не советую - слишком много подводных камней.
>>28495
>навайбкодить 2д-платформерошутан
Зачем вайбкодить, есть же готовый код на гитхабе.
https://github.com/SlayHorizon/godot-2d-platformer-demo
>в пиксельном стиле
Рисовать кто будет? Базовые нейронки не умеют.
>Годот хорошо подходит для такого?
Годот-то подходит, но хватит ли тебе усидчивости?
С какой целью в геймдев вкатываешься? Деньги?
Движкосрачи в движкосрачетред.
>>28510 (Del)
Да я ж говорю, мне похуй на мобилки. Пека-мак. Потому что там по механике норм клава нужна. Но этоу буквально первый вайб-проект, так что похер на какие-то тонкости, лишь бы MVP сделать.
>>28517
Так переделывать под свои хотелки как всегда дольше чем с нуля, не?
Я умею
Посмотрим
Нет, по фану
Да я ж говорю, мне похуй на мобилки. Пека-мак. Потому что там по механике норм клава нужна. Но этоу буквально первый вайб-проект, так что похер на какие-то тонкости, лишь бы MVP сделать.
>>28517
>Зачем вайбкодить, есть же готовый код на гитхабе.
Так переделывать под свои хотелки как всегда дольше чем с нуля, не?
>Рисовать кто будет? Базовые нейронки не умеют.
Я умею
>Годот-то подходит, но хватит ли тебе усидчивости?
Посмотрим
>С какой целью в геймдев вкатываешься? Деньги?
Нет, по фану
Не кормите дрищера. Есть загон для их кормежки.
>>28520
На Github ты можешь найти, прочитать и разобрать (осмыслить и усвоить) рабочий код чьей-то игры или шаблона для игры. Языковая модель (LLM) способна сгенерировать правдоподобную чепуху и ты потом замучаешься искать, в чём же проблема. А сама она слишком быстро забудет всё и запутается в коде.
Вообще, готовый же игровой движок берёшь. Почему собственный движок с нуля не сделаешь? Это же, по твоей логике, будет быстрее, чем брать готовый.
Если хочешь игру как хобби делать, лучше научиться программировать вручную, а LLM использовать как компаньона, а не замену твоих собственных рук. Так разбираться в ошибках и проблемах будет проще.
>>28521 (Del)
Нода нужна для рейкастов 60 раз в секунду.
Рейкаст через API - для одноразовых запросов.
Godot постоянно создаёт и удаляет некие внутренние объекты; так что создание Dictionary не так страшно, как кажется, конечно, если тебе не нужна тысяча этих словарей за один единственный кадр.
Ну, например, пути внутри .tscn абсолютные. Об этом известно много лет, но на относительные до сих пор не переделали. Догадаешься, почему это проблема?
Это же буквально несколько строчек кода... Но для огромного количества мобов/пуль нужны особые оптимизации независимо от движка и языка.
Там полно криворуких (и) перебежчиков с юнити.
Wat? Что за "стим индусы"? Индусы обычно пишут низкокачественный код задёшево. Имеешь в виду ассетфлиперные "издательства" типа Фалько?
>переделывать под свои хотелки как всегда дольше
На Github ты можешь найти, прочитать и разобрать (осмыслить и усвоить) рабочий код чьей-то игры или шаблона для игры. Языковая модель (LLM) способна сгенерировать правдоподобную чепуху и ты потом замучаешься искать, в чём же проблема. А сама она слишком быстро забудет всё и запутается в коде.
Вообще, готовый же игровой движок берёшь. Почему собственный движок с нуля не сделаешь? Это же, по твоей логике, будет быстрее, чем брать готовый.
>буквально первый вайб-проект
>Нет, по фану
Если хочешь игру как хобби делать, лучше научиться программировать вручную, а LLM использовать как компаньона, а не замену твоих собственных рук. Так разбираться в ошибках и проблемах будет проще.
>>28521 (Del)
>потребности рейкастить нодой
Нода нужна для рейкастов 60 раз в секунду.
Рейкаст через API - для одноразовых запросов.
Godot постоянно создаёт и удаляет некие внутренние объекты; так что создание Dictionary не так страшно, как кажется, конечно, если тебе не нужна тысяча этих словарей за один единственный кадр.
>есть еще проблемы?
Ну, например, пути внутри .tscn абсолютные. Об этом известно много лет, но на относительные до сих пор не переделали. Догадаешься, почему это проблема?
>столкнулся делая свой вампайр на 3 годоте
Это же буквально несколько строчек кода... Но для огромного количества мобов/пуль нужны особые оптимизации независимо от движка и языка.
>На 4 жалуюсь по шишкам других людей
Там полно криворуких (и) перебежчиков с юнити.
>геймдевил на закрывшихся стим индусов.
Wat? Что за "стим индусы"? Индусы обычно пишут низкокачественный код задёшево. Имеешь в виду ассетфлиперные "издательства" типа Фалько?
>>28528
А расскажи?
А то я за 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.
Чет не похоже на абсолютные.
А расскажи?
А то я за 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.
Чет не похоже на абсолютные.
101 Кб, 771x782>>28528
Хз, я еще когда только вышел гпт4, он написал мне алхимию на годоте. Ну да, пару десятков часов на отладку потратил, но игры с простыми механиками вполне реально клепать. Сейчас тем более клод 4 есть, еще умнее.
>Языковая модель (LLM) способна сгенерировать правдоподобную чепуху и ты потом замучаешься искать, в чём же проблема. А сама она слишком быстро забудет всё и запутается в коде.
Хз, я еще когда только вышел гпт4, он написал мне алхимию на годоте. Ну да, пару десятков часов на отладку потратил, но игры с простыми механиками вполне реально клепать. Сейчас тем более клод 4 есть, еще умнее.
>>28533 (Del)
В Хоппе 150 врагов без проблем выводится, хз о чем ты.
В Хоппе 150 врагов без проблем выводится, хз о чем ты.
>>28537 (Del)
А, так ты залетуха. Вопросов не имею.
А, так ты залетуха. Вопросов не имею.
>>28520
Вот это реальная заявка на победу. Без художественных скиллов в геймдеве делать нечего. А кодить тут не надо, весь код уже накодирован. Нейронка тебе выдаст ровно то, что накодили ранее и она на этом коде научилась.
> >Рисовать
> Я умею
Вот это реальная заявка на победу. Без художественных скиллов в геймдеве делать нечего. А кодить тут не надо, весь код уже накодирован. Нейронка тебе выдаст ровно то, что накодили ранее и она на этом коде научилась.
>>28540 (Del)
Такое мог ляпнуть только тот, кто тут не дольше пары месяцев.
Такое мог ляпнуть только тот, кто тут не дольше пары месяцев.
годот сила
>>28530 >>28533 (Del)
Ну, смотрите, у вас есть набор файлов:
Внутри box.tscn эти пути начинаются с, например:
Если папку "box" перекинуть в любую другую папку, ВНЕЗАПНО box.tscn не может обнаружить свои же собственные ресурсы, хотя их расположение никак не поменялось относительно box.tscn. Почему? Это наитупейшая проблема с точки зрения движка. Тем более что относительные пути МОЖНО записывать внутрь tscn, они корректно читаются, но сохранение изнутри редактора перезаписывает абсолютными.
Godot предлагает сейчас 3 решения:
1. Упаковать все ресурсы в tscn, сделав её жирной.
2. Полагаться на систему UID, которая ломается... Особенно при перемещении сцен в новый проект...
3. Каждый раз просматривать окошко сломанных зависимостей на предмет правильно найденных и потерянных, вручную выбрать правильные. Бесит.
ПОЧЕМУ нельзя было ПРОСТО сделать все пути относительными и не парить мозг пользователю?
При том что в GDScript load()/preload() принимают относительные пути как и следует, хотя если вы попытаетесь мышкой вставить - путь опять-таки абсолютным будет. Сейчас предлагают юзать UID, выглядящие как куча случайных символов и цифр, совершенно не похожие на название файла. Зачем?
Да, я часто перемещаю файлы, да, мне это НУЖНО.
Ну, смотрите, у вас есть набор файлов:
>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, выглядящие как куча случайных символов и цифр, совершенно не похожие на название файла. Зачем?
Да, я часто перемещаю файлы, да, мне это НУЖНО.
>>28541
Как и я - выдам то, чему научился и насмотрелся.
Но в целом я в геймдев и не рвусь, я же не шиз. Я планктон с нерелейтед работой, которому просто по фану что-то делать помимо работы.
>Нейронка тебе выдаст ровно то, что накодили ранее и она на этом коде научилась.
Как и я - выдам то, чему научился и насмотрелся.
Но в целом я в геймдев и не рвусь, я же не шиз. Я планктон с нерелейтед работой, которому просто по фану что-то делать помимо работы.
>>28544 (Del)
Ну в некотором смысле да, соглашусь, гейм-дизайн это тоже художественный скилл.
Ну в некотором смысле да, соглашусь, гейм-дизайн это тоже художественный скилл.
>>28546
Я тоже был против UID когда их ввели. Это решение решает одну проблему, создавая десяток новых. Неужели нельзя было сделать это опционально включаемым в настройках? Кто не хочет UIDы - продолжает без них. Кто хочет - включает их для этого конкретного проекта в настройках самостоятельно. Ждём когда Хуана хуями обложат в ишьюсах и он обратно откатит.
Я тоже был против UID когда их ввели. Это решение решает одну проблему, создавая десяток новых. Неужели нельзя было сделать это опционально включаемым в настройках? Кто не хочет UIDы - продолжает без них. Кто хочет - включает их для этого конкретного проекта в настройках самостоятельно. Ждём когда Хуана хуями обложат в ишьюсах и он обратно откатит.
>>28552 (Del)
Не, как я понял, пока что там путь + UID. Если UID нет, используется путь и UID добавляется заново (либо генерируется заново и добавляется). Т.е. вручную редактировать всё ещё достаточно просто.
Не нужно, достаточно относительных путей.
Я положил файл в папку. Я хочу найти файл в папке. Почему я должен разгадывать какие-то UID ребусы?
>>28551
Как я понимаю, это нужно в основном аддонам.
Вряд ли. Скорее заменят .uid на .meta для скриптов.
>вместо удобных ранее путей будут uuid
Не, как я понял, пока что там путь + UID. Если UID нет, используется путь и UID добавляется заново (либо генерируется заново и добавляется). Т.е. вручную редактировать всё ещё достаточно просто.
>долго коупили что uuid нинужна
Не нужно, достаточно относительных путей.
Я положил файл в папку. Я хочу найти файл в папке. Почему я должен разгадывать какие-то UID ребусы?
>>28551
>сделать это опционально включаемым
Как я понимаю, это нужно в основном аддонам.
>обложат в ишьюсах и он обратно откатит
Вряд ли. Скорее заменят .uid на .meta для скриптов.
>>28545 (Del)
Так Хоппа 3д, а не 2д, лол.
Так Хоппа 3д, а не 2д, лол.
>>28546
Вут? Основное решение тобой вообще не упомянуто. Оно заключается в том, чтобы перетаскивать папки в редакторе годота, а не внешнем проводнике.
Игры в годоте делай, а не как ОКРщик папки взад вперед таскай.
Вут? Основное решение тобой вообще не упомянуто. Оно заключается в том, чтобы перетаскивать папки в редакторе годота, а не внешнем проводнике.
Игры в годоте делай, а не как ОКРщик папки взад вперед таскай.
>>28563 (Del)
Бля люто двачую. Этот чупс шо в овг треде что тут итт своей хоппой серит, а я её ни в жизнь не видел.
Бля люто двачую. Этот чупс шо в овг треде что тут итт своей хоппой серит, а я её ни в жизнь не видел.
>>28564
Да ладно, не заливай. Ни разу не видел Хоппу? Не знал, что на небесах никуда без этого? Пойми, на небесах только и говорят, что о Хоппе.
Да ладно, не заливай. Ни разу не видел Хоппу? Не знал, что на небесах никуда без этого? Пойми, на небесах только и говорят, что о Хоппе.
Бля, а может быть это реально единичный шизоид который просто псиопом семенит лол
>>28564
Это что-то вроде мультиплеерных кнопок и синглтоновых антипаттернов. Болезнь короче.
Это что-то вроде мультиплеерных кнопок и синглтоновых антипаттернов. Болезнь короче.
84 Кб, 1032x586Простите это место где живет Монах Тома
В редакторе годота как-то можно сделать вывод графики по переменным сцены? Т.е. условно я на сцену уровня добавил сцену "Враг". У врага есть экспортная переменная для текстуры, которая потом в ready() задается спрайту. По умолчанию у врага текстура-заглушка, и в редакторе будет видна именно она. А можно ли сделать так, чтобы была видна именно текстура, заданная в экспорте? А то так я понадобавляю одинаковых сцен врагов или предметов с разными заданными текстурами, и хрен поймешь визуально кто где, не заглядывая в параметры каждой ноды и не запуская игру.
>>28594
Да, тебе нужен тулскрипт, ты пишешь @tool в начале файла и скрипт начинает работать в редакторе. Дальше сам.
Да, тебе нужен тулскрипт, ты пишешь @tool в начале файла и скрипт начинает работать в редакторе. Дальше сам.
>>28594
Я знаю что это возможно, но есть неочевидные подводные. Во первых нельзя написать @onready @export, это неопределенное поведение. Надо писать вот такой сеттер https://github.com/godotengine/godot-proposals/issues/325#issuecomment-1643230075
Во вторых надо придерживаться простой архитектуры, помню что будет какая то путаница с подсценами, особенно с inherited, editable и т.д., никогда не разобрался до конца, но что то глючило (сохраняло не в тлй)
Я знаю что это возможно, но есть неочевидные подводные. Во первых нельзя написать @onready @export, это неопределенное поведение. Надо писать вот такой сеттер https://github.com/godotengine/godot-proposals/issues/325#issuecomment-1643230075
Во вторых надо придерживаться простой архитектуры, помню что будет какая то путаница с подсценами, особенно с inherited, editable и т.д., никогда не разобрался до конца, но что то глючило (сохраняло не в тлй)
>>28592
Лучше бы я продолжал жить в счастливом неведении...
Лучше бы я продолжал жить в счастливом неведении...
>>28693
Есть бесплатный форк libresprite, но в обоих случаях мне неприятен пиксельный интерфейс для работы. Я предпочитаю чтобы интерфейс был векторный.
Есть бесплатный форк libresprite, но в обоих случаях мне неприятен пиксельный интерфейс для работы. Я предпочитаю чтобы интерфейс был векторный.
>>28707
Нахуя мне дополнительно узнавать про темы если всё что мне нужно есть искаропки в пиксельраме? Это проёб афтора этого вашего асприте, что он сделал ставку на пиксельщиков и не предоставил выбора искаропки. Темы ещё искать. Хррр-тьфу!
Нахуя мне дополнительно узнавать про темы если всё что мне нужно есть искаропки в пиксельраме? Это проёб афтора этого вашего асприте, что он сделал ставку на пиксельщиков и не предоставил выбора искаропки. Темы ещё искать. Хррр-тьфу!
>>28709
Вот это неожиданность.
Энивей, помимо пикселорамы (которая кстати на годоте), есть дефолтный набор гимп/инкскейп/крита. Еще недавно у Майка такую штуку смотрел, процедурный векторно-кодовый редактор Graphite: https://www.youtube.com/watch?v=LOyzKUevTEk
>программа для пиксель арта сделала ставку на пиксельщиков
Вот это неожиданность.
Энивей, помимо пикселорамы (которая кстати на годоте), есть дефолтный набор гимп/инкскейп/крита. Еще недавно у Майка такую штуку смотрел, процедурный векторно-кодовый редактор Graphite: https://www.youtube.com/watch?v=LOyzKUevTEk
>>28696
в асепрайте векторный интерфейс
в асепрайте векторный интерфейс
685 Кб, 1566x2048Тише, девочки, не ссорьтесь.
Pixelorama написана на GDScript в Godot 4.4.
https://github.com/Orama-Interactive/Pixelorama
Наш выбор очевиден, не так ли?
Продолжайте работу. Я слежу.
Pixelorama написана на GDScript в Godot 4.4.
https://github.com/Orama-Interactive/Pixelorama
Наш выбор очевиден, не так ли?
Продолжайте работу. Я слежу.
>>28720
Блять да че за хуйня.
В моей голове, хуманизированный годот выглядит как няшный шота с синими волосами и помошками.
Блять да че за хуйня.
В моей голове, хуманизированный годот выглядит как няшный шота с синими волосами и помошками.
90 Кб, 901x519https://forms.gle/FmCSVdQBDiuVLeJ99
Опросник годота для определения дальнейших направлений развития. Слышь, заполняй чтобы потом не ныть что твои хотелки игнорят.
Опросник годота для определения дальнейших направлений развития. Слышь, заполняй чтобы потом не ныть что твои хотелки игнорят.
>>28859 (Del)
Как сказать что ты залетный во всем айти, не говоря этого напрямую. Сыбись в свой дристотред, клован.
>две параллельные релизные версии вопреки всем здравым смыслам
Как сказать что ты залетный во всем айти, не говоря этого напрямую. Сыбись в свой дристотред, клован.
>>28859 (Del)
Не кормим.
Не кормим.
>>28864
Линукс довольно высоко как платформа, на которой разрабатывают. А как же хваленая макось?
Линукс довольно высоко как платформа, на которой разрабатывают. А как же хваленая макось?
>>28854
К лову данный опросник ну никак не влияет на направление развития, ну кроме как если там 90% окажется что пользователи небинарные для них сделают указание местоимений в ошибках которые выводятся в output
К лову данный опросник ну никак не влияет на направление развития, ну кроме как если там 90% окажется что пользователи небинарные для них сделают указание местоимений в ошибках которые выводятся в output
33 Кб, 666x666>>28859 (Del)
>>28865
Пора бы уже банить за упоминание 3.x всуе...
Нужно 2000 кадров КУБОВ на 18-летнем ПК?
Хотите фичи в тройке - бэкпортите их сами.
>запилили две параллельные релизные версии
>>28865
>забить на третью версию оставив её без фитч
Пора бы уже банить за упоминание 3.x всуе...
>легковесных быстрых рендеров из тройки
Нужно 2000 кадров КУБОВ на 18-летнем ПК?
Хотите фичи в тройке - бэкпортите их сами.
>>28887
Так это для пекабояр. А мы люди скромные, делаем в яндекс игры, а там без 3 никак. Да даже на нищепеках твгшников демка Хоппы на 4 так себе завелась, пришлось срочно дауншифтить.
Так это для пекабояр. А мы люди скромные, делаем в яндекс игры, а там без 3 никак. Да даже на нищепеках твгшников демка Хоппы на 4 так себе завелась, пришлось срочно дауншифтить.
>>28869
Опросник нужен для сбора статистики о пользователях.
Или ты предпочитаешь анальный зонд прямо в движке?
>>28903
И как тебе кормить рекламой маленьких детей?
У них там Пентиум?
СМАСТЕРИЛ КОМПЛЮДАХТЕР ИЗ ЧЕГО-ТО СОС ВАЛКИ
@
УКРАЛ ВИДИМОКАРТУ ИЗ КОМЛЮТЕРНОВО МУЗЕЯ
@
А ИГОРЬ ОТ ДВАЧИРОВ НЕ ЗАПЛЮСКАИТЬСЯ(((
@
ААААРРЯЯЯЯ, ВО ВСЕМ ХУАН ВИНОВАТ!!!
@
ЗРЯ ЖДАЛ СКАЧКИ ПО ДИАЛАПУ!!!
Игры всегда были излишеством для богатых.
>опросник ну никак не влияет на направление развития
Опросник нужен для сбора статистики о пользователях.
Или ты предпочитаешь анальный зонд прямо в движке?
>>28903
>яндекс игры
И как тебе кормить рекламой маленьких детей?
>на нищепеках твгшников
У них там Пентиум?
СМАСТЕРИЛ КОМПЛЮДАХТЕР ИЗ ЧЕГО-ТО СОС ВАЛКИ
@
УКРАЛ ВИДИМОКАРТУ ИЗ КОМЛЮТЕРНОВО МУЗЕЯ
@
А ИГОРЬ ОТ ДВАЧИРОВ НЕ ЗАПЛЮСКАИТЬСЯ(((
@
ААААРРЯЯЯЯ, ВО ВСЕМ ХУАН ВИНОВАТ!!!
@
ЗРЯ ЖДАЛ СКАЧКИ ПО ДИАЛАПУ!!!
Игры всегда были излишеством для богатых.
>>28867
Ну тащемта стереотип "линух - платформа для погромистов" не на пустом месте сформировался. Разработка действительно сильная сторона линукса. К тому же интерес к кодингу коррелирует с желанием поковыряться в системе - а это про линукс, но никак не про макось.
Олсо, из имеющихся средств разработки игр, Годот, пожалуй, проще всего установить. Скачал и запустил - всё. Никакой возни со сторонними репами или АУРом (хотя так тоже можно).
Ну и не забываем, что красноглазики в большинстве своём предпочитают опенсурсный софт. А яблочники предпочитают анальные зонды.
Ну тащемта стереотип "линух - платформа для погромистов" не на пустом месте сформировался. Разработка действительно сильная сторона линукса. К тому же интерес к кодингу коррелирует с желанием поковыряться в системе - а это про линукс, но никак не про макось.
Олсо, из имеющихся средств разработки игр, Годот, пожалуй, проще всего установить. Скачал и запустил - всё. Никакой возни со сторонними репами или АУРом (хотя так тоже можно).
Ну и не забываем, что красноглазики в большинстве своём предпочитают опенсурсный софт. А яблочники предпочитают анальные зонды.
12 Кб, 600x300>>28903
По опросу видно, что:
- только 92 человека пользуются 3.6 или ниже;
- целых 1938 человека экспортируют игры в веб.
Вывод: либо у тебя, либо у Яндекса скилл иссуе.
>делаем в яндекс игры, а там без 3 никак
По опросу видно, что:
- только 92 человека пользуются 3.6 или ниже;
- целых 1938 человека экспортируют игры в веб.
Вывод: либо у тебя, либо у Яндекса скилл иссуе.
>>28954
Хе-хе, мой юный падаван.
1938 человек жамкнувших экспорт "моя первая 2д игра на геймджем на итче, в котороую запустит 10 человек и пох на лаги" не то же самое, что делать игру в условиях конкуренции и с определенной планкой требовний к качству, скорости загрузки/размера билда, поведения аудио и прочее.
Хе-хе, мой юный падаван.
1938 человек жамкнувших экспорт "моя первая 2д игра на геймджем на итче, в котороую запустит 10 человек и пох на лаги" не то же самое, что делать игру в условиях конкуренции и с определенной планкой требовний к качству, скорости загрузки/размера билда, поведения аудио и прочее.
>>28955
Бля, было бы не так смешно говори ты хотя бы о гугл-плее с его аудиторией на весь мир и миллиардными установками.
покормил мимо проходя
>делает игру в локальный яндекс-лягушатник
>задвигает о конкуренции и планках качества
Бля, было бы не так смешно говори ты хотя бы о гугл-плее с его аудиторией на весь мир и миллиардными установками.
покормил мимо проходя
>>28957
Чел, я в России, а не европках. Почему мне нужна легковесная 3-ка, я пояснил. 4-ка мне не уперлась, а то что ее ставит 95% пользователей и так понятно - она "свежая", она первая на сайте. Только вот они могут игр и не делать, а просто поковыряться в туториалах и потом проголосовать в этих опросах.
Чел, я в России, а не европках. Почему мне нужна легковесная 3-ка, я пояснил. 4-ка мне не уперлась, а то что ее ставит 95% пользователей и так понятно - она "свежая", она первая на сайте. Только вот они могут игр и не делать, а просто поковыряться в туториалах и потом проголосовать в этих опросах.
Чому в треде так чувствительны к объективной критике движка? Мне он нравится например и я на нем делаю свою первую дрочильню, но как только упомянул об отрицательных сторонах в треде так сразу "репорт и игнорим" лол. Или это один кто-то бегает и создает видимость?
Pixelorama - это спрайты.
В ней же рисуем текстуры?
В ней же рисуем текстуры?
>>29006
Пчел, я тоже из РФ, и если ты не смог обойти сосанкции то ты уже проиграл конкуренцию. О какой конкуренции ты теперь вообще можешь задвигать, тебя выдавили на задворки, на крошечный рынок, все, твоя конкуренция теперь за гроб и кладбище.
Пчел, я тоже из РФ, и если ты не смог обойти сосанкции то ты уже проиграл конкуренцию. О какой конкуренции ты теперь вообще можешь задвигать, тебя выдавили на задворки, на крошечный рынок, все, твоя конкуренция теперь за гроб и кладбище.
83 Кб, 480x640Графика:
Blockbench - для 3D-моделей.
Pixelorama - всё 2D.
А что подобного есть для музыки и звуков, чтобы просто из блоков делать?
Blockbench - для 3D-моделей.
Pixelorama - всё 2D.
А что подобного есть для музыки и звуков, чтобы просто из блоков делать?
>>29019
Смотря что за музыка и звуки тебе нужны. Для чиптюн-стиля есть плагины типа godot-sfxr, не помню какой именно сейчас популярный, позволяют генерить звуковые эффекты прямо в движке. Музыка в чиптюне - Bosca Ceoil Blue - тоже на годоте, тоже опенсорс, если что сможешь пнуть разработчика ПРЯМО НА РУССКОМ, ПОТОМУ ЧТО ОН РУССКИЙ! ЕЕЕ! Весь яндекс будет твой.
Смотря что за музыка и звуки тебе нужны. Для чиптюн-стиля есть плагины типа godot-sfxr, не помню какой именно сейчас популярный, позволяют генерить звуковые эффекты прямо в движке. Музыка в чиптюне - Bosca Ceoil Blue - тоже на годоте, тоже опенсорс, если что сможешь пнуть разработчика ПРЯМО НА РУССКОМ, ПОТОМУ ЧТО ОН РУССКИЙ! ЕЕЕ! Весь яндекс будет твой.
>>29018
если ты не смог обойти обрыжью мозгопромывку, то ты проиграл по жизни
если ты не смог обойти обрыжью мозгопромывку, то ты проиграл по жизни
710 Кб, 1400x2000Отлично, с битовыми графикой и звучанием мы разобрались.
Это для новичков, для тренировки, для набросков.
А что с высоким качеством, для продвинутых и профессионалов?
(И мы не говорим про нейронки, мы говорим про софт, который создаёт на 100% именно то, что нам надо, с разной степенью автоматизации.)
Графика:
Модели:
Blender
Рисование:
Gimp/Krita (от руки), Inkscape.
Больше ничего не надо?
То есть самые топовые опенсорсные софтины для моделей и рисования, тут всё просто.
А с музыкой/звуками что?
Редактор/"изменятель готового", следуя аналогии - это Audacity, однозначно.
А с созданием звука что?
Создаватели звука в опен сорсе - они в природе существуют вообще?
Это для новичков, для тренировки, для набросков.
А что с высоким качеством, для продвинутых и профессионалов?
(И мы не говорим про нейронки, мы говорим про софт, который создаёт на 100% именно то, что нам надо, с разной степенью автоматизации.)
Графика:
Модели:
Blender
Рисование:
Gimp/Krita (от руки), Inkscape.
Больше ничего не надо?
То есть самые топовые опенсорсные софтины для моделей и рисования, тут всё просто.
А с музыкой/звуками что?
Редактор/"изменятель готового", следуя аналогии - это Audacity, однозначно.
А с созданием звука что?
Создаватели звука в опен сорсе - они в природе существуют вообще?
Ладно, прекращаю кормить.
>>29023
LMMS есть опенсорсный для создания музыки, слегка кривоват, но пойдёт
созданием звуков с нуля никто или почти никто не занимается, если у тебя нет под это отдельного специалиста, все используют готовые библиотеки
LMMS есть опенсорсный для создания музыки, слегка кривоват, но пойдёт
созданием звуков с нуля никто или почти никто не занимается, если у тебя нет под это отдельного специалиста, все используют готовые библиотеки
220 Кб, 338x553>>29027
Да, есть Lmms и Ardour, они позволяют собирать большие звуки/музыку из небольших блоков, дают редактировать готовые аудиозаписи при помощи мини-редакторов, которые вставляются в эти блоки-кирпичики.
Понятно, что большинство юзает всё готовое, как и с текстурами, копипастингом кода скриптов, готовым игровым движком в конце концов итд.
Но что сложного может быть с созданием звука с нуля?
Свет - это электро-магнитные волны.
Звук - это волны/вибрация воздуха или другого проводника.
Свет мы режем/(представляем в виде) на пиксели, векторы итд и воспроизводим.
Так что сложного со звуком может быть? Он же ещё проще.
Какое ПО юзают эти немногочисленные специалисты?
Подключение электрогитары итд к компу и создание музыки таким образом, к примеру - это бред, здесь нет никакой универсальности.
Да, есть Lmms и Ardour, они позволяют собирать большие звуки/музыку из небольших блоков, дают редактировать готовые аудиозаписи при помощи мини-редакторов, которые вставляются в эти блоки-кирпичики.
Понятно, что большинство юзает всё готовое, как и с текстурами, копипастингом кода скриптов, готовым игровым движком в конце концов итд.
Но что сложного может быть с созданием звука с нуля?
Свет - это электро-магнитные волны.
Звук - это волны/вибрация воздуха или другого проводника.
Свет мы режем/(представляем в виде) на пиксели, векторы итд и воспроизводим.
Так что сложного со звуком может быть? Он же ещё проще.
Какое ПО юзают эти немногочисленные специалисты?
Подключение электрогитары итд к компу и создание музыки таким образом, к примеру - это бред, здесь нет никакой универсальности.
>>29029
ну ты либо игры делаешь, либо звуки синтезируешь
с нуля можно синтезировать простые алгоритмические звуки: взрывы, выстрелы, раскаты грома, рокот мотора и т. д.
всё остальное проще записать
используют max/msp, reaktor, есть бесплатный puredata
ну ты либо игры делаешь, либо звуки синтезируешь
с нуля можно синтезировать простые алгоритмические звуки: взрывы, выстрелы, раскаты грома, рокот мотора и т. д.
всё остальное проще записать
используют max/msp, reaktor, есть бесплатный puredata
>>29030
щас погуглил что взрослые дяди используют для саундизайна: Phase plant, Arturia pigments, UVI Falcon
а также Soundminer, Sound particles - несколько другого рода программы
разумеется, для соло инди энтузиастов это оверкил
щас погуглил что взрослые дяди используют для саундизайна: Phase plant, Arturia pigments, UVI Falcon
а также Soundminer, Sound particles - несколько другого рода программы
разумеется, для соло инди энтузиастов это оверкил
77 Кб, 832x1216Так вы все поймите вот что.
1) Когда вы делаете говноподелку (учебный/тестовый/экспериментальный проект, говноигра для общего веса в пакет, бесконечные задумки, на которые никогда нет времени, чтобы довести до ума - просто очередной проект-заметка...), - здесь вы копипастите всё готовое. "Хуяк-хуяк и в продакшн". (Можно даже о лицензиях не запариваться, от слова вообще.)
Тут вы берёте готовые текстуры, музыку, звуки, глючный индусокод от нейронок, который не понятно чо делает вообще итд.
2) Когда вы делаете более качественный проект (минимальное - начальное среднее качество), уже на продажу или + для карьеры итп, вы начинаете редактировать, графику набиваете из пикселей с нуля, берёте Audacity и подобные и правите звуки, чтобы они хоть как-то подходили, обрезаете лишнее итд.
Музыку вообще бесплатную и без правок закидываете в проект.
Звук всегда отстаёт от графики по качеству проработки и детализации, потому что первой в глаза бросается картинка, а звуки - это фон, второй план (стрельба,...), музыка - третий.
3) Если это ещё более качественный проект (уже точно нормальное качество, всё серьёзно и честно, тут вы пытаетесь заработать реально вкладываясь), то вы берёте уже хорошие графические редакторы GIMPы (проприетарные аналоги) итд, а для музыки начинаете юзать секвенсоры (LMMS и Ardour или проприетарные), ну потому что теперь уже не только отдельные звуки должны хорошо подходить к игре, но и сама музыка и вы либо покупаете, либо делаете сами, в обоих случаях с различной степенью автоматизации производства контента.
4) И напоследок...
Высококачественные игры и Шедевры, игры в которые вы вкладываете душу и сердце, годы разработки, бессонные ночи, убитые нервная система и психика.
Это для профессионалов, а не игроделов-однодневок.
При помощи этих проектов вы пытаетесь выбиться в люди, а не просто подзаработать, хотите из грязи в князи итп.
А ваша мечта - сделать ещё один Майнкрафт, но в других, ещё не занятых, нишах и продать за млрд.
Здесь, когда вы пытаетесь погрузить игроков в ваш выдуманный виртуальный фантастический мир целиком и полностью, атмосфера, всё с иголочки, ничего лишнего и отсутствующего, тут уже всё, и даже музыка/звуки наконец догоняют графику и всё остальное и покупаются или делаются с нуля чётко под эту игру и они изначально такие, какие должны быть.
А покупать - это либо дорого, когда всё честно, либо наебалово и там говноподелка. И вообще наебалово теперь уже просто везде.
Короче, просто берёшь и делаешь сам.
И здесь ты просто БОГ, ты создатель мира с самого нуля. Ты, как будто бы, манипулируешь нулями и единицами (через GUI) и создаёшь целые вселенные.
Вот для этого последнего пункта и нужно ПО, создающее звук/музыку с самого нуля.
Но, как вы понимаете, таких игр меньшинство, большинство недоигроделов не запаривается (тем более это одноразовые игроделы), аналогично даже с недопрофессиональными музыкоделами, шлёпающими музло из кирпичей в секвенсорах для попсовых говнотреков, пипл схавает, людей с хорошим слухом мало,...
Ну и поэтому в итоге эта часть ПО, для создания всего звука с нуля, оказывается просто крайне недоразвитой, это то, что мы и имеем в реальности.
Для графики - жопой ешь, для звука - нихера не найдёшь.
1) Когда вы делаете говноподелку (учебный/тестовый/экспериментальный проект, говноигра для общего веса в пакет, бесконечные задумки, на которые никогда нет времени, чтобы довести до ума - просто очередной проект-заметка...), - здесь вы копипастите всё готовое. "Хуяк-хуяк и в продакшн". (Можно даже о лицензиях не запариваться, от слова вообще.)
Тут вы берёте готовые текстуры, музыку, звуки, глючный индусокод от нейронок, который не понятно чо делает вообще итд.
2) Когда вы делаете более качественный проект (минимальное - начальное среднее качество), уже на продажу или + для карьеры итп, вы начинаете редактировать, графику набиваете из пикселей с нуля, берёте Audacity и подобные и правите звуки, чтобы они хоть как-то подходили, обрезаете лишнее итд.
Музыку вообще бесплатную и без правок закидываете в проект.
Звук всегда отстаёт от графики по качеству проработки и детализации, потому что первой в глаза бросается картинка, а звуки - это фон, второй план (стрельба,...), музыка - третий.
3) Если это ещё более качественный проект (уже точно нормальное качество, всё серьёзно и честно, тут вы пытаетесь заработать реально вкладываясь), то вы берёте уже хорошие графические редакторы GIMPы (проприетарные аналоги) итд, а для музыки начинаете юзать секвенсоры (LMMS и Ardour или проприетарные), ну потому что теперь уже не только отдельные звуки должны хорошо подходить к игре, но и сама музыка и вы либо покупаете, либо делаете сами, в обоих случаях с различной степенью автоматизации производства контента.
4) И напоследок...
Высококачественные игры и Шедевры, игры в которые вы вкладываете душу и сердце, годы разработки, бессонные ночи, убитые нервная система и психика.
Это для профессионалов, а не игроделов-однодневок.
При помощи этих проектов вы пытаетесь выбиться в люди, а не просто подзаработать, хотите из грязи в князи итп.
А ваша мечта - сделать ещё один Майнкрафт, но в других, ещё не занятых, нишах и продать за млрд.
Здесь, когда вы пытаетесь погрузить игроков в ваш выдуманный виртуальный фантастический мир целиком и полностью, атмосфера, всё с иголочки, ничего лишнего и отсутствующего, тут уже всё, и даже музыка/звуки наконец догоняют графику и всё остальное и покупаются или делаются с нуля чётко под эту игру и они изначально такие, какие должны быть.
А покупать - это либо дорого, когда всё честно, либо наебалово и там говноподелка. И вообще наебалово теперь уже просто везде.
Короче, просто берёшь и делаешь сам.
И здесь ты просто БОГ, ты создатель мира с самого нуля. Ты, как будто бы, манипулируешь нулями и единицами (через GUI) и создаёшь целые вселенные.
Вот для этого последнего пункта и нужно ПО, создающее звук/музыку с самого нуля.
Но, как вы понимаете, таких игр меньшинство, большинство недоигроделов не запаривается (тем более это одноразовые игроделы), аналогично даже с недопрофессиональными музыкоделами, шлёпающими музло из кирпичей в секвенсорах для попсовых говнотреков, пипл схавает, людей с хорошим слухом мало,...
Ну и поэтому в итоге эта часть ПО, для создания всего звука с нуля, оказывается просто крайне недоразвитой, это то, что мы и имеем в реальности.
Для графики - жопой ешь, для звука - нихера не найдёшь.
77 Кб, 832x1216Так вы все поймите вот что.
1) Когда вы делаете говноподелку (учебный/тестовый/экспериментальный проект, говноигра для общего веса в пакет, бесконечные задумки, на которые никогда нет времени, чтобы довести до ума - просто очередной проект-заметка...), - здесь вы копипастите всё готовое. "Хуяк-хуяк и в продакшн". (Можно даже о лицензиях не запариваться, от слова вообще.)
Тут вы берёте готовые текстуры, музыку, звуки, глючный индусокод от нейронок, который не понятно чо делает вообще итд.
2) Когда вы делаете более качественный проект (минимальное - начальное среднее качество), уже на продажу или + для карьеры итп, вы начинаете редактировать, графику набиваете из пикселей с нуля, берёте Audacity и подобные и правите звуки, чтобы они хоть как-то подходили, обрезаете лишнее итд.
Музыку вообще бесплатную и без правок закидываете в проект.
Звук всегда отстаёт от графики по качеству проработки и детализации, потому что первой в глаза бросается картинка, а звуки - это фон, второй план (стрельба,...), музыка - третий.
3) Если это ещё более качественный проект (уже точно нормальное качество, всё серьёзно и честно, тут вы пытаетесь заработать реально вкладываясь), то вы берёте уже хорошие графические редакторы GIMPы (проприетарные аналоги) итд, а для музыки начинаете юзать секвенсоры (LMMS и Ardour или проприетарные), ну потому что теперь уже не только отдельные звуки должны хорошо подходить к игре, но и сама музыка и вы либо покупаете, либо делаете сами, в обоих случаях с различной степенью автоматизации производства контента.
4) И напоследок...
Высококачественные игры и Шедевры, игры в которые вы вкладываете душу и сердце, годы разработки, бессонные ночи, убитые нервная система и психика.
Это для профессионалов, а не игроделов-однодневок.
При помощи этих проектов вы пытаетесь выбиться в люди, а не просто подзаработать, хотите из грязи в князи итп.
А ваша мечта - сделать ещё один Майнкрафт, но в других, ещё не занятых, нишах и продать за млрд.
Здесь, когда вы пытаетесь погрузить игроков в ваш выдуманный виртуальный фантастический мир целиком и полностью, атмосфера, всё с иголочки, ничего лишнего и отсутствующего, тут уже всё, и даже музыка/звуки наконец догоняют графику и всё остальное и покупаются или делаются с нуля чётко под эту игру и они изначально такие, какие должны быть.
А покупать - это либо дорого, когда всё честно, либо наебалово и там говноподелка. И вообще наебалово теперь уже просто везде.
Короче, просто берёшь и делаешь сам.
И здесь ты просто БОГ, ты создатель мира с самого нуля. Ты, как будто бы, манипулируешь нулями и единицами (через GUI) и создаёшь целые вселенные.
Вот для этого последнего пункта и нужно ПО, создающее звук/музыку с самого нуля.
Но, как вы понимаете, таких игр меньшинство, большинство недоигроделов не запаривается (тем более это одноразовые игроделы), аналогично даже с недопрофессиональными музыкоделами, шлёпающими музло из кирпичей в секвенсорах для попсовых говнотреков, пипл схавает, людей с хорошим слухом мало,...
Ну и поэтому в итоге эта часть ПО, для создания всего звука с нуля, оказывается просто крайне недоразвитой, это то, что мы и имеем в реальности.
Для графики - жопой ешь, для звука - нихера не найдёшь.
1) Когда вы делаете говноподелку (учебный/тестовый/экспериментальный проект, говноигра для общего веса в пакет, бесконечные задумки, на которые никогда нет времени, чтобы довести до ума - просто очередной проект-заметка...), - здесь вы копипастите всё готовое. "Хуяк-хуяк и в продакшн". (Можно даже о лицензиях не запариваться, от слова вообще.)
Тут вы берёте готовые текстуры, музыку, звуки, глючный индусокод от нейронок, который не понятно чо делает вообще итд.
2) Когда вы делаете более качественный проект (минимальное - начальное среднее качество), уже на продажу или + для карьеры итп, вы начинаете редактировать, графику набиваете из пикселей с нуля, берёте Audacity и подобные и правите звуки, чтобы они хоть как-то подходили, обрезаете лишнее итд.
Музыку вообще бесплатную и без правок закидываете в проект.
Звук всегда отстаёт от графики по качеству проработки и детализации, потому что первой в глаза бросается картинка, а звуки - это фон, второй план (стрельба,...), музыка - третий.
3) Если это ещё более качественный проект (уже точно нормальное качество, всё серьёзно и честно, тут вы пытаетесь заработать реально вкладываясь), то вы берёте уже хорошие графические редакторы GIMPы (проприетарные аналоги) итд, а для музыки начинаете юзать секвенсоры (LMMS и Ardour или проприетарные), ну потому что теперь уже не только отдельные звуки должны хорошо подходить к игре, но и сама музыка и вы либо покупаете, либо делаете сами, в обоих случаях с различной степенью автоматизации производства контента.
4) И напоследок...
Высококачественные игры и Шедевры, игры в которые вы вкладываете душу и сердце, годы разработки, бессонные ночи, убитые нервная система и психика.
Это для профессионалов, а не игроделов-однодневок.
При помощи этих проектов вы пытаетесь выбиться в люди, а не просто подзаработать, хотите из грязи в князи итп.
А ваша мечта - сделать ещё один Майнкрафт, но в других, ещё не занятых, нишах и продать за млрд.
Здесь, когда вы пытаетесь погрузить игроков в ваш выдуманный виртуальный фантастический мир целиком и полностью, атмосфера, всё с иголочки, ничего лишнего и отсутствующего, тут уже всё, и даже музыка/звуки наконец догоняют графику и всё остальное и покупаются или делаются с нуля чётко под эту игру и они изначально такие, какие должны быть.
А покупать - это либо дорого, когда всё честно, либо наебалово и там говноподелка. И вообще наебалово теперь уже просто везде.
Короче, просто берёшь и делаешь сам.
И здесь ты просто БОГ, ты создатель мира с самого нуля. Ты, как будто бы, манипулируешь нулями и единицами (через GUI) и создаёшь целые вселенные.
Вот для этого последнего пункта и нужно ПО, создающее звук/музыку с самого нуля.
Но, как вы понимаете, таких игр меньшинство, большинство недоигроделов не запаривается (тем более это одноразовые игроделы), аналогично даже с недопрофессиональными музыкоделами, шлёпающими музло из кирпичей в секвенсорах для попсовых говнотреков, пипл схавает, людей с хорошим слухом мало,...
Ну и поэтому в итоге эта часть ПО, для создания всего звука с нуля, оказывается просто крайне недоразвитой, это то, что мы и имеем в реальности.
Для графики - жопой ешь, для звука - нихера не найдёшь.
>>29038
Да
Да
>>29038
аниме, ты не разбираешься ни в саунддизайне, ни в композиторском искусстве настолько, что даже нет смысла тебе отвечать
твоя простыня что то уровня "а как игру написать в блокноте чтобы она в exe запускалось", ну или что-то типа того, был тут один такой когда-то
аниме, ты не разбираешься ни в саунддизайне, ни в композиторском искусстве настолько, что даже нет смысла тебе отвечать
твоя простыня что то уровня "а как игру написать в блокноте чтобы она в exe запускалось", ну или что-то типа того, был тут один такой когда-то
>>29043
Это мимикрирующий движкосрачер. Он ничего не делает и не собирается делать, только охуительные истории придумывает и дерейлит тред на хуйню, меняя свои хотелки с каждым постом.
Не ведитесь.
Это мимикрирующий движкосрачер. Он ничего не делает и не собирается делать, только охуительные истории придумывает и дерейлит тред на хуйню, меняя свои хотелки с каждым постом.
Не ведитесь.
91 Кб, 640x640>>29043
>>29047
Я абсолютно согласен, не будем вестись на долбоёбов.
Давайте лучше поговорим про ненужность геймдевов больше.
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
>>29047
Я абсолютно согласен, не будем вестись на долбоёбов.
Давайте лучше поговорим про ненужность геймдевов больше.
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
>>29052
если я тебе отвечу, это получится, что я повёлся на долбоёба, так что не буду
если я тебе отвечу, это получится, что я повёлся на долбоёба, так что не буду
>>29038
Каким вообще образом ты определяешь то, какая игра будет говноподелкой, а какая нет?
Или ты из шизоидов кто в единственную и неповторимую игру мечты верит?
>>29052
Скоро наебнет много ии игр. Они явно обвалят рыночек геймдева.
И это даже хорошо. Если в геймдеве не останется легких денег, то кабанчики, любители легкой наживы, и прочий сброд которым молотком по голове полоснуть хочется съебут из индустрии, и остануться только те, кто реально любит делать игры.
Поскорее бы все это сгорело, что бы я, спокойно, на углях прошлого величия, мог делать те игры, которые люблю и жить спокойно.
Каким вообще образом ты определяешь то, какая игра будет говноподелкой, а какая нет?
Или ты из шизоидов кто в единственную и неповторимую игру мечты верит?
>>29052
Скоро наебнет много ии игр. Они явно обвалят рыночек геймдева.
И это даже хорошо. Если в геймдеве не останется легких денег, то кабанчики, любители легкой наживы, и прочий сброд которым молотком по голове полоснуть хочется съебут из индустрии, и остануться только те, кто реально любит делать игры.
Поскорее бы все это сгорело, что бы я, спокойно, на углях прошлого величия, мог делать те игры, которые люблю и жить спокойно.
>остануться только те, кто реально любит делать игры.
Для кого останутся то? Если это говно будет рисовать тебе любую игру какую хошь, с потенциально бесконечным контентом. Игровая индустрия будет как в "Город и звезды", где ты с корешами напяливаешь вр шлем и тебе нейронка рисует приключение, каждый раз новое. Это наступит не сейчас и возможно даже не через 5 лет, но наступит обязательно, и скорее рано чем поздно.
1,4 Мб, 1690x2048>>29058
Ты упускаешь ряд важных вещей, и особенно:
В начале...
Игр/фильмов/музтреков станет больше, чем игроков, когда их начнут штамповать.
У большинства игр/фильмов/треков... будет ноль покупок, ноль игроков/зрителей, у большей части из меньшего - 1 игрок/зритель/слушатель итд.
А далее...
Игры будут генериться реал-тайм на мощных серверах, затем на девайсах пользователей, под каждого конкретного игрока, то, что хочет конкретный индивид со всей, присущей ему спецификой, аналогично, с фильмами, музыкой итд
Онлайн умрёт к хуям.
А сраные элитки, приберут к своим руками всё окончательно, узкий круг, а всех остальных конкурентов опустят в грязь.
Население планеты, подключив остатки к системе, погрузят в цифровой концлагерь, и будут манипулировать ними, как хотят.
Я про всё это когда-то давно уже писал на двачах.
Ты упускаешь ряд важных вещей, и особенно:
В начале...
Игр/фильмов/музтреков станет больше, чем игроков, когда их начнут штамповать.
У большинства игр/фильмов/треков... будет ноль покупок, ноль игроков/зрителей, у большей части из меньшего - 1 игрок/зритель/слушатель итд.
А далее...
Игры будут генериться реал-тайм на мощных серверах, затем на девайсах пользователей, под каждого конкретного игрока, то, что хочет конкретный индивид со всей, присущей ему спецификой, аналогично, с фильмами, музыкой итд
Онлайн умрёт к хуям.
А сраные элитки, приберут к своим руками всё окончательно, узкий круг, а всех остальных конкурентов опустят в грязь.
Население планеты, подключив остатки к системе, погрузят в цифровой концлагерь, и будут манипулировать ними, как хотят.
Я про всё это когда-то давно уже писал на двачах.
>>29069
Сынок, ты чего?
Сынок, ты чего?
>>29038
"ГТА Санкт-Петербург" уже доделал?
>>29047
Он из ньюфаготреда - видно, таблетки пьёт.
Раньше даже по клавишам не попадал.
Порадуемся за его выздоровление!
>>29055
Только в них играть никто кроме тебя не будет.
А делать игры тебе и сейчас никто не мешает.
>>29065
Да кому твой мясной мешок нужен? У элиты ИИ.
"ГТА Санкт-Петербург" уже доделал?
>>29047
>Это мимикрирующий движкосрачер
Он из ньюфаготреда - видно, таблетки пьёт.
Раньше даже по клавишам не попадал.
Порадуемся за его выздоровление!
>>29055
>мог делать те игры, которые люблю
Только в них играть никто кроме тебя не будет.
А делать игры тебе и сейчас никто не мешает.
>>29065
>будут манипулировать ними, как хотят
Да кому твой мясной мешок нужен? У элиты ИИ.
>>29080
Ты имел ввиду, у ИИ ненужные элиты?
Прост с исчезновением мясных мешков рабов, ненужными становятся и мясные мешки илитки.
>Да кому твой мясной мешок нужен? У элиты ИИ.
Ты имел ввиду, у ИИ ненужные элиты?
Прост с исчезновением мясных мешков рабов, ненужными становятся и мясные мешки илитки.
>>29090
Если хочешь серьёзно это обсудить...
Есть огромная разница между "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 замутил. Но конкретного применения не нашёл и опять забросил. Короче, нужно сперва с применением определиться.
Если хочешь серьёзно это обсудить...
Есть огромная разница между "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 замутил. Но конкретного применения не нашёл и опять забросил. Короче, нужно сперва с применением определиться.
>>29090
Если хочешь серьёзно это обсудить...
Есть огромная разница между "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 замутил. Но конкретного применения не нашёл и опять забросил. Короче, нужно сперва с применением определиться.
Если хочешь серьёзно это обсудить...
Есть огромная разница между "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 замутил. Но конкретного применения не нашёл и опять забросил. Короче, нужно сперва с применением определиться.
>>29116
зарепортил нерелейтед. для аи есть загон.
зарепортил нерелейтед. для аи есть загон.
919 Кб, 2000x2000>>29116
Не слушай репортодебила и расскажи пожалуйста подробнее, это очень интересно.
>попробовал нейроны на GDScript учить
Не слушай репортодебила и расскажи пожалуйста подробнее, это очень интересно.
>>29080
Я с этим давно столкнулся братишь
И я... Не жалуюсь. Мне не иронично нравиться то что я там делаю.
>Только в них играть никто кроме тебя не будет.
Я с этим давно столкнулся братишь
И я... Не жалуюсь. Мне не иронично нравиться то что я там делаю.
>>29080
Уверен? >>1029081 →
Прям вообще никто? Могу выливать все содержимое своего мозга в коробку, награмождать это визуалом, музыкой и геймплеем и никто не взбугуртнет да не прийдет за моей сракой?
Мне мешают.
>А делать игры тебе и сейчас никто не мешает
Уверен? >>1029081 →
Прям вообще никто? Могу выливать все содержимое своего мозга в коробку, награмождать это визуалом, музыкой и геймплеем и никто не взбугуртнет да не прийдет за моей сракой?
Мне мешают.
>>29131
Гдачую, делать игры приятно... когда получается.
>>29134
Придти за тобой могут только если ты публикуешь в интернете что-то запрещённое, поскольку интернет - публичное место и/или СМИ. За хранение чего-то на домашнем компе просто так не придут, необходимо доказать, что ты что-то скрываешь (УПК РФ Статья 182. Основания и порядок производства обыска).
Вообще, речь шла о генеративном ИИ: >>29055
Анону "кабанчики" запрещают делать игры? Нет.
>Мне не иронично нравиться то что я там делаю.
Гдачую, делать игры приятно... когда получается.
>>29134
>никто не взбугуртнет да не прийдет за моей сракой
Придти за тобой могут только если ты публикуешь в интернете что-то запрещённое, поскольку интернет - публичное место и/или СМИ. За хранение чего-то на домашнем компе просто так не придут, необходимо доказать, что ты что-то скрываешь (УПК РФ Статья 182. Основания и порядок производства обыска).
Вообще, речь шла о генеративном ИИ: >>29055
>...ии игр. Они явно обвалят рыночек геймдева.
>...кабанчики... съебут из индустрии...
Анону "кабанчики" запрещают делать игры? Нет.
>>29136
Я просто поделился о наболевшем.
Любишь черный юмор?
Тебе нельзя добавлять его в игру.
Почему?
Терпи.
Я просто поделился о наболевшем.
Любишь черный юмор?
Тебе нельзя добавлять его в игру.
Почему?
Терпи.
>>29023
Digital Audio Workstations
Если есть деньги, надо брать Reaper, некоторые известные мне музыканты его рекомендовали, ну а если денег нет, то LMMS...
> А с созданием звука что?
Digital Audio Workstations
Если есть деньги, надо брать Reaper, некоторые известные мне музыканты его рекомендовали, ну а если денег нет, то LMMS...
>>29138
надо брать фл студию с кряком
пользуюсь 22 года, полёт нормальный
кстати LMMS похож на старые версии фрути лупс, с отставанием лет на 10
надо брать фл студию с кряком
пользуюсь 22 года, полёт нормальный
кстати LMMS похож на старые версии фрути лупс, с отставанием лет на 10
>>29141
С кряком сложно будет потом, если игра взлетит. Но игра-то не взлетит, так что можно и рипер крякнуть.
С кряком сложно будет потом, если игра взлетит. Но игра-то не взлетит, так что можно и рипер крякнуть.
>>29146
Ага, именно с этих слов начинаются судебные дела. А ещё такие, говорят, "как вы меня нашли))".
> ничего не будет
Ага, именно с этих слов начинаются судебные дела. А ещё такие, говорят, "как вы меня нашли))".
>>29147
сколько судов выиграл?
покажи мне юр. лицо image line в России
ты просто трус который боится вылезти из своей скорлупы, премудрый пискарь
сколько судов выиграл?
покажи мне юр. лицо image line в России
ты просто трус который боится вылезти из своей скорлупы, премудрый пискарь
>>29148
нет конечно, нищая трясущаяся омежка боится даже игру выложить в стим т.к. за ним придёт товарищ майор а компании подадут в суд
у омежки нет денег
нет конечно, нищая трясущаяся омежка боится даже игру выложить в стим т.к. за ним придёт товарищ майор а компании подадут в суд
у омежки нет денег
>>29150
Это так. Но в вопросе софта я последовательный сторонник авторских прав, потому что когда ты вылезешь из своей скорлупы в стим (в отличие от меня, труса, разумеется) то тебе не хотелось бы увидеть свою игру на торрентах через день.
> ты просто трус
Это так. Но в вопросе софта я последовательный сторонник авторских прав, потому что когда ты вылезешь из своей скорлупы в стим (в отличие от меня, труса, разумеется) то тебе не хотелось бы увидеть свою игру на торрентах через день.
>>29009
База
У годота оч много минусов
Но он мне поэтому и нравиться
я не хочу что бы мне движок из коробки игру собирал.
База
У годота оч много минусов
Но он мне поэтому и нравиться
я не хочу что бы мне движок из коробки игру собирал.
>>29166
Нету признаков
Нету признаков
300 Кб, 1070x1058Так какая Open Source прога позволяет создавать с нуля на компе звуки?
>>29197
звукозапись windows + микрофон
звукозапись windows + микрофон
>>29197
Если ты имеешь ввиду DAW, то LMMS или Ardour первыми в голову приходят. Оба попенсорсные и бесплатные, есть встроенные инструменты как везде, у LMMS ещё от старых консолей вроде NES или SMD + встроенная поддержка наборов семплов SF2, в которые обычно собирают наборы из других старых консолек нинтенды, но при желании можно найти такие же бесплатные и на другие программы. Плюс можешь подобавлять бесплатно распростаняемые VST с интернетов, plugin4free.com как пример, тоже синтезаторы и семплеры всякие для музыки. Сам ими не пользовался, но про LMMS говорят, что очень похожа на FL Studio, которая мне в целом нравится, и ещё вроде как их проекты имеют совместимость между программами. Ardour тоже вроде советуют.
И так, отсебятина. Если говорить о трекинговой музыке, как встарину для игр писали, то лучше всего будет Furnace. Тоже опенсорс, там много разных эмулируемых чипов, есть поддержка семплерных и можно спиздить инструменты с форума платного DefleMask, у которого нормальное такое коммунити, благодаря обратной совместимости.
Если ты имеешь ввиду DAW, то LMMS или Ardour первыми в голову приходят. Оба попенсорсные и бесплатные, есть встроенные инструменты как везде, у LMMS ещё от старых консолей вроде NES или SMD + встроенная поддержка наборов семплов SF2, в которые обычно собирают наборы из других старых консолек нинтенды, но при желании можно найти такие же бесплатные и на другие программы. Плюс можешь подобавлять бесплатно распростаняемые VST с интернетов, plugin4free.com как пример, тоже синтезаторы и семплеры всякие для музыки. Сам ими не пользовался, но про LMMS говорят, что очень похожа на FL Studio, которая мне в целом нравится, и ещё вроде как их проекты имеют совместимость между программами. Ardour тоже вроде советуют.
И так, отсебятина. Если говорить о трекинговой музыке, как встарину для игр писали, то лучше всего будет Furnace. Тоже опенсорс, там много разных эмулируемых чипов, есть поддержка семплерных и можно спиздить инструменты с форума платного DefleMask, у которого нормальное такое коммунити, благодаря обратной совместимости.
>>29224
Окстись, юродивый, не набрасывай, он просит DAW что бы звуки делать, а не что бы мануалы по ней читать. К тому же Reaper:
- Не бесплатный (я знаю про закрытие окошка оплаты, но с таким же успехом он может просто с торрентов что нибудь нормальное скачать)
- Не опенсорсный
Окстись, юродивый, не набрасывай, он просит DAW что бы звуки делать, а не что бы мануалы по ней читать. К тому же Reaper:
- Не бесплатный (я знаю про закрытие окошка оплаты, но с таким же успехом он может просто с торрентов что нибудь нормальное скачать)
- Не опенсорсный
>>29246
Меньше трать время на кормежку тупых троллей, а вероятнее сам меньше тролль тупостью, и тоже что-нибудь сделаешь.
Меньше трать время на кормежку тупых троллей, а вероятнее сам меньше тролль тупостью, и тоже что-нибудь сделаешь.
>>29262
Тролль, не неси хуйню.
Тролль, не неси хуйню.
>>29148
Неиронично пользуюсь FLOSS софтом... Кроме Windows и Steam.
Платный софт - это:
- баги не фиксятся десятилетиями, ибо корпораты к ним привыкли;
- техподдержка только за отдельные деньги, фанбои ничё не знают;
- уродливый ГУЙ от яждизайнерши, без хоткеев, без кастомизации;
- новые фичи суют без разбора, но недоделывают и забрасывают;
- анальный зонд + принудительные платные обновления;
- запланированное устаревание старых версий;
- гарантия тормозов, ибо шизофреймворки;
- если краш: 0 логов, "вы сами виноваты".
FLOSS - это:
- баги фиксятся (по мере возможности), ибо софтом реально пользуются;
- техподдержки нет, зато тёплое и дружное коммьюнити программистов;
- очень практичный ГУЙ от программистов, с хоткеями и кастомизацией;
- новые фичи - при необходимости, их доделывают и поддерживают;
- анальных зондов практически не бывает, обновления по желанию;
- старые версии с очень долгой поддержкой, работают как часы;
- софт летает даже на древнем железе, ибо написан с нуля;
- если краш: логи, дебаггер, багрепорты, всё как у людей.
ИМХО, платным софтом в основном пользуются дети и офисные рабы.
С Windows просто так получилось, что на неё намного больше софта...
>вы не иронично софт покупаете
Неиронично пользуюсь FLOSS софтом... Кроме Windows и Steam.
Платный софт - это:
- баги не фиксятся десятилетиями, ибо корпораты к ним привыкли;
- техподдержка только за отдельные деньги, фанбои ничё не знают;
- уродливый ГУЙ от яждизайнерши, без хоткеев, без кастомизации;
- новые фичи суют без разбора, но недоделывают и забрасывают;
- анальный зонд + принудительные платные обновления;
- запланированное устаревание старых версий;
- гарантия тормозов, ибо шизофреймворки;
- если краш: 0 логов, "вы сами виноваты".
FLOSS - это:
- баги фиксятся (по мере возможности), ибо софтом реально пользуются;
- техподдержки нет, зато тёплое и дружное коммьюнити программистов;
- очень практичный ГУЙ от программистов, с хоткеями и кастомизацией;
- новые фичи - при необходимости, их доделывают и поддерживают;
- анальных зондов практически не бывает, обновления по желанию;
- старые версии с очень долгой поддержкой, работают как часы;
- софт летает даже на древнем железе, ибо написан с нуля;
- если краш: логи, дебаггер, багрепорты, всё как у людей.
ИМХО, платным софтом в основном пользуются дети и офисные рабы.
С Windows просто так получилось, что на неё намного больше софта...
>>29325
Ребенок плиз, на дворе литерали 2026 год, а опенсорс до сих пор не в состоянии свободно работать с простейшими форматами ворда и экселя не распидорашивая их, и до сих пор нет копии фотошопа причем все настолько тухло, что приходится пользоваться photopea в БРАУЗЕРЕ. Что уж говорить про специфический софт из любой дорогой профессии.
Ребенок плиз, на дворе литерали 2026 год, а опенсорс до сих пор не в состоянии свободно работать с простейшими форматами ворда и экселя не распидорашивая их, и до сих пор нет копии фотошопа причем все настолько тухло, что приходится пользоваться photopea в БРАУЗЕРЕ. Что уж говорить про специфический софт из любой дорогой профессии.
>>29338
Лол. Пользуюсь LibreOffice, полёт нормальный.
Лол. Пользуюсь Krita + Inkscape, полёт нормальный.
Ты пишешь софт под промышленные станки? ROS.
>>29345
Опеначую, закрытый формат == потерянные данные.
>простейшими форматами ворда и экселя
Лол. Пользуюсь LibreOffice, полёт нормальный.
>нет копии фотошопа
Лол. Пользуюсь Krita + Inkscape, полёт нормальный.
>специфический софт из любой дорогой профессии
Ты пишешь софт под промышленные станки? ROS.
>>29345
>Не пользуйся кривыми закрытыми форматами
Опеначую, закрытый формат == потерянные данные.
>>29338
ну и на хер тогда игры! :(
ну и на хер тогда игры! :(
>>29365
Плоскость с SubViewport материалом. И что в этом такого?
Самое сложное в порталах - тени и бесшовный телепорт.
Лучше бы геймплей продумывал, чем спецэффекты.
Плоскость с SubViewport материалом. И что в этом такого?
Самое сложное в порталах - тени и бесшовный телепорт.
Лучше бы геймплей продумывал, чем спецэффекты.
>>29365
Круто, продолжай!
Круто, продолжай!
>>29352
Ага помню-помню, софт где кисть ЛАГАЕТ за мышкой когда ей ведешь по экрану на пекарне с любыми спеками, даже photopea в браузере на телефоне отзывчивее.
>>29345
Ага сейчас побегу сотне рабочих контактов рассказывать, чтобы перестали слать мне свои эксельки, а сам начну им слать неоткрываемые ничем .odsdgrjabfr документы. Успокойся уже, сынок, опер сорс не просто так сосет хуи на задних рядах.
>Krita
Ага помню-помню, софт где кисть ЛАГАЕТ за мышкой когда ей ведешь по экрану на пекарне с любыми спеками, даже photopea в браузере на телефоне отзывчивее.
>>29345
>Не пользуйся кривыми закрытыми форматами
Ага сейчас побегу сотне рабочих контактов рассказывать, чтобы перестали слать мне свои эксельки, а сам начну им слать неоткрываемые ничем .odsdgrjabfr документы. Успокойся уже, сынок, опер сорс не просто так сосет хуи на задних рядах.
>>29370
Это новые стенсили из 4.5 beta
Это новые стенсили из 4.5 beta
Проебался хуй знает сколько часов в попытках сделать густой черный дым из трубы и получил говно какое-то жидкое с этими вашими гпу партиклами 3д. Может у кого-то есть гайды на эту тему?
>>29374
Дружище, я много лет работаю с документами всевозможных направлений в либреофисе, если тебе присылают какие-то таблички, прейскуранты, то вообще пофиг, если присылают какие то хитровыебанные макросы которые работают только в экселе, с такими шизиками проще не работать сразу. У них все равно все наебнется когда такого кулибина собъет автобус и окажется что только один знал как работает его экселька.
Дружище, я много лет работаю с документами всевозможных направлений в либреофисе, если тебе присылают какие-то таблички, прейскуранты, то вообще пофиг, если присылают какие то хитровыебанные макросы которые работают только в экселе, с такими шизиками проще не работать сразу. У них все равно все наебнется когда такого кулибина собъет автобус и окажется что только один знал как работает его экселька.
>>29384
Я наваливаю 3д партикли с мешами-кубами, меняю им с таймингом через курвы альбедо, размер, дампинг и все такое, плюс рандомизирую немного. Мне нраица, постил в соцсети - челам тоже зашло. Но мне стиль игры позволяет кубами срать, а чего там у тебя хз, в реализм я не умею.
Я наваливаю 3д партикли с мешами-кубами, меняю им с таймингом через курвы альбедо, размер, дампинг и все такое, плюс рандомизирую немного. Мне нраица, постил в соцсети - челам тоже зашло. Но мне стиль игры позволяет кубами срать, а чего там у тебя хз, в реализм я не умею.
>>29374
Это называется сглаживание, ньюфажек. Настраивается в "Tool Options".
Подсказка: без сглаживания МЫШКОЙ ты ничего нормально не нарисуешь.
Будь сигма чэдом, а не шестёркой на побегушках у каких-то богатых дураков.
>>29388
Двачую. А лучше вообще не работать ни с кем и делать игры в соло.
>кисть ЛАГАЕТ за мышкой
Это называется сглаживание, ньюфажек. Настраивается в "Tool Options".
Подсказка: без сглаживания МЫШКОЙ ты ничего нормально не нарисуешь.
>сотне рабочих контактов
Будь сигма чэдом, а не шестёркой на побегушках у каких-то богатых дураков.
>>29388
>с такими шизиками проще не работать сразу
Двачую. А лучше вообще не работать ни с кем и делать игры в соло.
>>29384
Ты новичок? Вот тут про огонь: >>958174 →
Просто густой дым сделать намного проще.
Вкратце, тебе нужно:
- текстура с шумом и гладкими неровными краями;
- определиться с основным направлением и скоростью;
- добавить очень много рандома в направление и скорость.
>сделать густой черный дым из трубы
Ты новичок? Вот тут про огонь: >>958174 →
Просто густой дым сделать намного проще.
Вкратце, тебе нужно:
- текстура с шумом и гладкими неровными краями;
- определиться с основным направлением и скоростью;
- добавить очень много рандома в направление и скорость.
6 Кб, 256x256>>29122
Долго думал, но так и не понял, что именно рассказать?
То, что сегодня называют "нейросетями", придумали ещё в 1943 году. Простейшая сеть состоит из простейших нейронов, а простейший нейрон - это взвешенная сумма чисел на входе и простая функция активации, преобразующая эту сумму в вывод нейрона (это тип максимально упрощённая модель поведения биологического нейрона, или, по крайней мере, раньше так считали). Т.е. простейший нейрон на GDScript можно реализовать так (неоптимально, но суть работы нейронки передаёт):
Вот, собственно, и всё. Осталось самое сложное: найти подходящие числа в 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)?
А если несколько единиц и остальное по нулям?
Кажется, у такой модели какое-то название есть. Понятия не имею, какое. Но умножений тут вообще нет, поэтому производительность должна вырасти значительно. А ещё нет лишних операций, потому что отсутствующие сигналы никак не симулируются (это нули). Но, наверное, у такой модели сильно ограниченная сфера применения, поэтому её не используют. На GPU такое считать бессмысленно.
"Winner takes all" выглядит как-то так, если для одного слоя нейронов:
Вообще-то я всё это в классы обернул (RefCounted), но это не важно...
>расскажи пожалуйста подробнее, это очень интересно
Долго думал, но так и не понял, что именно рассказать?
То, что сегодня называют "нейросетями", придумали ещё в 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), но это не важно...
6 Кб, 256x256>>29122
Долго думал, но так и не понял, что именно рассказать?
То, что сегодня называют "нейросетями", придумали ещё в 1943 году. Простейшая сеть состоит из простейших нейронов, а простейший нейрон - это взвешенная сумма чисел на входе и простая функция активации, преобразующая эту сумму в вывод нейрона (это тип максимально упрощённая модель поведения биологического нейрона, или, по крайней мере, раньше так считали). Т.е. простейший нейрон на GDScript можно реализовать так (неоптимально, но суть работы нейронки передаёт):
Вот, собственно, и всё. Осталось самое сложное: найти подходящие числа в 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)?
А если несколько единиц и остальное по нулям?
Кажется, у такой модели какое-то название есть. Понятия не имею, какое. Но умножений тут вообще нет, поэтому производительность должна вырасти значительно. А ещё нет лишних операций, потому что отсутствующие сигналы никак не симулируются (это нули). Но, наверное, у такой модели сильно ограниченная сфера применения, поэтому её не используют. На GPU такое считать бессмысленно.
"Winner takes all" выглядит как-то так, если для одного слоя нейронов:
Вообще-то я всё это в классы обернул (RefCounted), но это не важно...
>расскажи пожалуйста подробнее, это очень интересно
Долго думал, но так и не понял, что именно рассказать?
То, что сегодня называют "нейросетями", придумали ещё в 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), но это не важно...
14 Кб, 512x512>>26834 (OP) >>1026807 →
Если кого-то ещё это затронуло:
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:
Моя топовая игровая сборка E5450 + 750 Ti тащит 99% игр в 30+ FPS.
И во многих играх я намного чаще "GPU-limited", чем "CPU-limited"...
Даже игры на UE5 умудряются занять 100% GPU, не заполняя CPU.
Ладно. Всё равно планирую собрать новый ПК... через пару лет...
Думаю подождать выхода DDR6, какие подводные? Или DDR5 норм?
>У меня 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 норм?
>>29522
Меня это как то затронуло в html версии, там в эмскиптене тоже какая то зависимость повысилась поэтому на совсем некроноуте веб версия 4-ки не запускалась, а тройки запускалась. (Там вместо CPU стоит что то вроде Intel T4500)
Меня это как то затронуло в html версии, там в эмскиптене тоже какая то зависимость повысилась поэтому на совсем некроноуте веб версия 4-ки не запускалась, а тройки запускалась. (Там вместо CPU стоит что то вроде Intel T4500)
Иногда запускаю годо на ноуте 2010-го года с i3 330m, посмотрел — SSE 4.2 есть, лол. Нормально.
5 Кб, 400x200>>29552
При том что E5450 быстрее на 150%. И мне его более чем хватает на веб-сёрфинг, многие игры, Godot, Blender и всё остальное. Правда, Blender после 4.1 теперь тоже требует SSE 4.2 и вроде даже AVX2. Но я вообще без понятия, зачем нужны новые версии Blender, если там ничего особо нового не делают больше. Обновления Godot хотя бы новые функции в GDScript добавляют и баги фиксят.
Единственное что хотелось GPT локально запускать - что-то крупнее 1.5b работает слишком медленно. Но я читал, что для этих нейронок скорость RAM важнее, чем CPU/GPU, и поэтому логичнее будет подождать DDR6 или следующего поколения VRAM.
Не понимаю, куда торопиться, пока всё работает...
>i3 330m
При том что E5450 быстрее на 150%. И мне его более чем хватает на веб-сёрфинг, многие игры, Godot, Blender и всё остальное. Правда, Blender после 4.1 теперь тоже требует SSE 4.2 и вроде даже AVX2. Но я вообще без понятия, зачем нужны новые версии Blender, если там ничего особо нового не делают больше. Обновления Godot хотя бы новые функции в GDScript добавляют и баги фиксят.
Единственное что хотелось GPT локально запускать - что-то крупнее 1.5b работает слишком медленно. Но я читал, что для этих нейронок скорость RAM важнее, чем CPU/GPU, и поэтому логичнее будет подождать DDR6 или следующего поколения VRAM.
Не понимаю, куда торопиться, пока всё работает...
>>29571 (Del)
ты ещё и вахтёр?
ты ещё и вахтёр?
>>29566
Ты.
Ты.
>>29566
Деньги-то есть... Просто мотивации возиться с покупкой и сборкой ПК нет. Я и с этим компьютером намучился - то одно не работает, то другое внезапно отваливается. Но я кое-как отладил его и теперь стабильность на все 100, ни одного BSoD за несколько лет. А я живу по принципу "работает - не трогай". Как представлю, сколько нервотрёпки с выбором компонентов, покупкой, сборкой и настройкой нового ПК, заменой бракованных компонентов (сначала поди разберись, что именно бракованное), установке ОС и всех драйверов, переустановке всего софта... Зачем мне это? Чтоб с глупым чатботом без интернета общаться, лол? Или чтоб в очередную бездушную ААА, которую поленились оптимизировать, сливать всё свободное время? Нет мотивации возиться ради таких мелочей. У меня мотивации едва хватает на то, чтобы встать с кровати и поесть, какой там новый компьютер...
Присматривался к мини-ПК, у которых всё уже собрано. Но они слабые и дорогие, меня жаба душит покупать какой-то обрубок нормального ПК без перспектив расширения за стоимость почти топовой сборки нормальной башни (поэтому у меня никогда не было и не будет консоли - зачем мне какой-то неполноценный ПК по цене полноценного?).
Ты лучше игры свои показывай. Покажи делом, насколько лучше работать на современном ПК.
inb4 "таблетки пей": от таких таблеток тупым становишься, есть опыт.
>нищеброд
Деньги-то есть... Просто мотивации возиться с покупкой и сборкой ПК нет. Я и с этим компьютером намучился - то одно не работает, то другое внезапно отваливается. Но я кое-как отладил его и теперь стабильность на все 100, ни одного BSoD за несколько лет. А я живу по принципу "работает - не трогай". Как представлю, сколько нервотрёпки с выбором компонентов, покупкой, сборкой и настройкой нового ПК, заменой бракованных компонентов (сначала поди разберись, что именно бракованное), установке ОС и всех драйверов, переустановке всего софта... Зачем мне это? Чтоб с глупым чатботом без интернета общаться, лол? Или чтоб в очередную бездушную ААА, которую поленились оптимизировать, сливать всё свободное время? Нет мотивации возиться ради таких мелочей. У меня мотивации едва хватает на то, чтобы встать с кровати и поесть, какой там новый компьютер...
Присматривался к мини-ПК, у которых всё уже собрано. Но они слабые и дорогие, меня жаба душит покупать какой-то обрубок нормального ПК без перспектив расширения за стоимость почти топовой сборки нормальной башни (поэтому у меня никогда не было и не будет консоли - зачем мне какой-то неполноценный ПК по цене полноценного?).
Ты лучше игры свои показывай. Покажи делом, насколько лучше работать на современном ПК.
inb4 "таблетки пей": от таких таблеток тупым становишься, есть опыт.
>>29583
Тебе не нужно расширение, потому что с твоим майндсетом ты никогда не будешь расширять. Поэтому тебе надо просто взять игровой ноут где уже все подобрано. Сам сижу на катане с i7 чет там и 3060.
(И нет, собирать компы просто, там очень редко бывают описанные тобой несовместимости, это что-то из 2000-х, но и это легко решалось просто списком от каких нибудь оверклокеров которые уже написали что с чем совместимо. Я так к 775 сокету память подбирал и там прямо было написано какие производители какие планки и какие цифирки вписывать. Буквально пару дней на выяснение всего).
Тебе не нужно расширение, потому что с твоим майндсетом ты никогда не будешь расширять. Поэтому тебе надо просто взять игровой ноут где уже все подобрано. Сам сижу на катане с i7 чет там и 3060.
(И нет, собирать компы просто, там очень редко бывают описанные тобой несовместимости, это что-то из 2000-х, но и это легко решалось просто списком от каких нибудь оверклокеров которые уже написали что с чем совместимо. Я так к 775 сокету память подбирал и там прямо было написано какие производители какие планки и какие цифирки вписывать. Буквально пару дней на выяснение всего).
>>29589
Докину что к ноуту можно подключить второй внешний монитор и вообще заебись, самое то для геймдева.
Докину что к ноуту можно подключить второй внешний монитор и вообще заебись, самое то для геймдева.
>>29594
Прикольно, но меня затошнило. Лучше закрепи бар слева, чтобы он увеличивался вправо, а не чтоб в обе стороны расходился.
Прикольно, но меня затошнило. Лучше закрепи бар слева, чтобы он увеличивался вправо, а не чтоб в обе стороны расходился.
>>29594
Норм. Главное чтобы с остальным интерфейсом сочетался. Это же не вещь в себе? Это же прогрессбар для твоей игры в этом же стиле?
Норм. Главное чтобы с остальным интерфейсом сочетался. Это же не вещь в себе? Это же прогрессбар для твоей игры в этом же стиле?
>>29600
>>29624
>>29652
Идея такая: зажимание клавиши увеличивает заряд способности, которая имеет несколько мощностей. Полностью заряжается за 1-2 секунды. Смысл резко переключать сегменты в том, чтобы можно было не фокусироваться на прогресс-баре, боковым зрением оценивая, на какой стадии находится способность - например, чтобы не перебрать с мощностью удара.
Стиля нет. Мне проще делать-переделывать GUI, чем работать над реальным геймплеем... В голове образ геймплея с GUI был, вот и реализовал что попроще. Интересно было, как оно получится в реальности. В принципе, есть вероятность, что GUI тут не нужен.
Цвета подразумевают каление металла, узнали?
Как же не хочется трогать контроллер персонажа...
>чтобы он увеличивался вправо
>>29624
>немножко конечно статики хочется
>>29652
>Это же не вещь в себе?
Идея такая: зажимание клавиши увеличивает заряд способности, которая имеет несколько мощностей. Полностью заряжается за 1-2 секунды. Смысл резко переключать сегменты в том, чтобы можно было не фокусироваться на прогресс-баре, боковым зрением оценивая, на какой стадии находится способность - например, чтобы не перебрать с мощностью удара.
Стиля нет. Мне проще делать-переделывать GUI, чем работать над реальным геймплеем... В голове образ геймплея с GUI был, вот и реализовал что попроще. Интересно было, как оно получится в реальности. В принципе, есть вероятность, что GUI тут не нужен.
Цвета подразумевают каление металла, узнали?
Как же не хочется трогать контроллер персонажа...
>>29673
Ничего... Просто я столько с ним мучился, что теперь ассоциации неприятные и мотивация падает, только представлю как там всё опять сломается. Нужно всё рефакторить на конечный автомат, но не выходит.
Ничего... Просто я столько с ним мучился, что теперь ассоциации неприятные и мотивация падает, только представлю как там всё опять сломается. Нужно всё рефакторить на конечный автомат, но не выходит.
4 Кб, 112x133Сап анонасы, какой youtube-канал, торрент-раздачу или книгу для освоения Godot посоветуете? Все что я нахожу в основном устарело, сделано любителем и не охватывает все темы, либо же на английском.
>>29860
Я придумал гта 7, только в 7 раз больше и живее и с разрушаемым окружением и крафтом как в майнкрафте. А ты?
Я придумал гта 7, только в 7 раз больше и живее и с разрушаемым окружением и крафтом как в майнкрафте. А ты?
>>29875
Переводы на любой язык всегда будут устаревать, иметь дыры и неточности. Исходный язык всего айти - английский. Учи. Либо пользуйся переводчиками, они сейчас все с нейросетями и отлично справляются. Ютубы можешь переводить/озвучивать яндекс браузером. Но лучше сам учи, технический английский не сложный и его словарный набор минимален. БОльшая часть основателей годота не нативные инглиш спикеры, там португальский-французский-испанский и хуй знает еще какая смесь, но ведь осилили английский.
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
Вроде оно переведено на русский, но кто знает насколько точно:
https://docs.godotengine.org/ru/4.x/getting_started/introduction/
Переводы на любой язык всегда будут устаревать, иметь дыры и неточности. Исходный язык всего айти - английский. Учи. Либо пользуйся переводчиками, они сейчас все с нейросетями и отлично справляются. Ютубы можешь переводить/озвучивать яндекс браузером. Но лучше сам учи, технический английский не сложный и его словарный набор минимален. БОльшая часть основателей годота не нативные инглиш спикеры, там португальский-французский-испанский и хуй знает еще какая смесь, но ведь осилили английский.
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
Вроде оно переведено на русский, но кто знает насколько точно:
https://docs.godotengine.org/ru/4.x/getting_started/introduction/
36 Кб, 295x416>>29884
Есть там методология. По моим ссылкам вполне себе учебник, от теории и знакомства с движком, до пошагового создания 2д и 3д игры. Сам так вкатывался.
Есть там методология. По моим ссылкам вполне себе учебник, от теории и знакомства с движком, до пошагового создания 2д и 3д игры. Сам так вкатывался.
>>29884
А методологию, уж извини меня за прямоту, но ты должен был знать до вката в геймдев. Если тебе нужна методология, то тебе в общее айти, паттерны учи, солид, банду четырёх. Как осознаешь, возвращайся.
Есть _____-переводчик. 2025 год на дворе, алё.
> нет методологии
А методологию, уж извини меня за прямоту, но ты должен был знать до вката в геймдев. Если тебе нужна методология, то тебе в общее айти, паттерны учи, солид, банду четырёх. Как осознаешь, возвращайся.
> Есть на русском?
Есть _____-переводчик. 2025 год на дворе, алё.
>>29887
А ну да
Я художник и аниматор 3D графики (в портфолио Metro Exodus, Сралкер 2, Atomic Heart 2, вне портфолио секретный проект Owlcat)
По профессиональному образованию звукорежиссер
Умею хорошо рисовать
Умею кодить на Python (приоритет 3D-графика)
Знаю UE5, но работать с ним не хочу из-за лицензии для России
Я могу читать на английском, но это плохо сказывается на восприятии материала
У меня мозги забиты под завязку, плюс мне 32+ лет, когда чтобы воспринимать новую информацию нужно формировать стратегию обучения. Поэтому, я интересуюсь уровнем методологии в материале, это банально в концепции тайм менеджмента. Я просто обосновал свой запрос, никаких ответов не требуется. Спасибо за то что ответил.
>А методологию, уж извини меня за прямоту, но ты должен был знать до вката в геймдев
А ну да
Я художник и аниматор 3D графики (в портфолио Metro Exodus, Сралкер 2, Atomic Heart 2, вне портфолио секретный проект Owlcat)
По профессиональному образованию звукорежиссер
Умею хорошо рисовать
Умею кодить на Python (приоритет 3D-графика)
Знаю UE5, но работать с ним не хочу из-за лицензии для России
Я могу читать на английском, но это плохо сказывается на восприятии материала
У меня мозги забиты под завязку, плюс мне 32+ лет, когда чтобы воспринимать новую информацию нужно формировать стратегию обучения. Поэтому, я интересуюсь уровнем методологии в материале, это банально в концепции тайм менеджмента. Я просто обосновал свой запрос, никаких ответов не требуется. Спасибо за то что ответил.
>>29902
Методология геймдева осваиваивается за полную среднюю школу на практически 90% задач. Если у тебя в голове аглебра и тригонометрия не выветрились - большая часть задач решаются в пределах полного среднего образования + понимание кватернионов, которое в целом не слишком обязательно. Для геймдизайна уже может потребоваться матанализ, в часности ряды для формирования бесконечной но строго определяемой прогрессии. Для стандартного геймдева - операции с матрицами, операции с векторами, набор некоторых математических приемов, которые просто надо иметь возможность прочесть в вики и реализовать - и вот тебе методология. Всё это заполировать структурами данных из любого языка (все виды коллекций и хранилищ информации) - ты геймдев разумнее 80% рынка.
Методология геймдева осваиваивается за полную среднюю школу на практически 90% задач. Если у тебя в голове аглебра и тригонометрия не выветрились - большая часть задач решаются в пределах полного среднего образования + понимание кватернионов, которое в целом не слишком обязательно. Для геймдизайна уже может потребоваться матанализ, в часности ряды для формирования бесконечной но строго определяемой прогрессии. Для стандартного геймдева - операции с матрицами, операции с векторами, набор некоторых математических приемов, которые просто надо иметь возможность прочесть в вики и реализовать - и вот тебе методология. Всё это заполировать структурами данных из любого языка (все виды коллекций и хранилищ информации) - ты геймдев разумнее 80% рынка.
>>29923
Нейронки кстати отлично помогают понять нужную математику. Видимо в тренировочном датасете матана у них полно. Если с кодом они лажают, то математику уровня геймдева объясняют на 10 из 10.
Нейронки кстати отлично помогают понять нужную математику. Видимо в тренировочном датасете матана у них полно. Если с кодом они лажают, то математику уровня геймдева объясняют на 10 из 10.
>>29878
Не думаю, что ты на это способен.
У меня щас третий проект в "придумывании", готовлю детальное ТЗ со сценарием, геймдизайном и пр.
>Я придумал гта 7
Не думаю, что ты на это способен.
>А ты?
У меня щас третий проект в "придумывании", готовлю детальное ТЗ со сценарием, геймдизайном и пр.
>>30023
У меня уже тридцать третий проект придуман, каждый второй - шедевр. За один придуманный проект я вообще награды получал. Тоже придуманные, конечно. И придумано вырвался в топчарты стима. Мои придуманные фанаты ждут не дождутся моей следующей придумки. А сколько у меня придуманых профитов срублено с этих шедевров, ууу, ты и придумать не способен.
Кстати, я уже упоминал что каждая кнопка в моих проектах - мультиплеерная? Вот так вот я придумал клево
У меня уже тридцать третий проект придуман, каждый второй - шедевр. За один придуманный проект я вообще награды получал. Тоже придуманные, конечно. И придумано вырвался в топчарты стима. Мои придуманные фанаты ждут не дождутся моей следующей придумки. А сколько у меня придуманых профитов срублено с этих шедевров, ууу, ты и придумать не способен.
Кстати, я уже упоминал что каждая кнопка в моих проектах - мультиплеерная? Вот так вот я придумал клево
>>30030
Ты несмешно шутишь, шути смешнее.
>>30023
Сириусли? Ты в ГТА вообще играл? Рецепт ГТА:
- реальный город, но урезанный в масштабе;
- тачки и пушки почти как ИРЛ, но аркадные;
- НПЦ ходят по кругу, копы таранят по прямой;
- весь сюжет: "ноунейм пацан к успеху пришёл";
- всё это обильно посыпано шутками про говно.
Тут и придумывать нечего, всё придумали в 90-х.
Алсо, все ГТА полны багов и проблем геймплея.
>>29902
Что такой занятой человек забыл на дваче?
Слишком толстый тролль, попробуй потоньше.
>>29875
Достаточно документации.
>>29884
Что именно тебе нужно?
Для проекта по фану как хобби в одиночку:
1. Скачиваешь и запускаешь Godot 4+.
2. Делаешь свою игру.
3. Играешь.
Для работы в команде следуешь методам команды.
Godot можно использовать по-разному:
- как внешнюю библиотеку;
- как площадку для своих модулей;
- как конструктор игр из компонентов.
Каждый способ имеет множество вариаций.
В IT нет лучших путей, всегда масса альтернатив.
Ты несмешно шутишь, шути смешнее.
>>30023
>>Я придумал гта 7
>Не думаю, что ты на это способен.
Сириусли? Ты в ГТА вообще играл? Рецепт ГТА:
- реальный город, но урезанный в масштабе;
- тачки и пушки почти как ИРЛ, но аркадные;
- НПЦ ходят по кругу, копы таранят по прямой;
- весь сюжет: "ноунейм пацан к успеху пришёл";
- всё это обильно посыпано шутками про говно.
Тут и придумывать нечего, всё придумали в 90-х.
Алсо, все ГТА полны багов и проблем геймплея.
>>29902
Что такой занятой человек забыл на дваче?
Слишком толстый тролль, попробуй потоньше.
>>29875
>для освоения Godot
Достаточно документации.
>>29884
>нет методологии
Что именно тебе нужно?
Для проекта по фану как хобби в одиночку:
1. Скачиваешь и запускаешь Godot 4+.
2. Делаешь свою игру.
3. Играешь.
Для работы в команде следуешь методам команды.
Godot можно использовать по-разному:
- как внешнюю библиотеку;
- как площадку для своих модулей;
- как конструктор игр из компонентов.
Каждый способ имеет множество вариаций.
В IT нет лучших путей, всегда масса альтернатив.
>>30030
Ты несмешно шутишь, шути смешнее.
>>30023
Сириусли? Ты в ГТА вообще играл? Рецепт ГТА:
- реальный город, но урезанный в масштабе;
- тачки и пушки почти как ИРЛ, но аркадные;
- НПЦ ходят по кругу, копы таранят по прямой;
- весь сюжет: "ноунейм пацан к успеху пришёл";
- всё это обильно посыпано шутками про говно.
Тут и придумывать нечего, всё придумали в 90-х.
Алсо, все ГТА полны багов и проблем геймплея.
>>29902
Что такой занятой человек забыл на дваче?
Слишком толстый тролль, попробуй потоньше.
>>29875
Достаточно документации.
>>29884
Что именно тебе нужно?
Для проекта по фану как хобби в одиночку:
1. Скачиваешь и запускаешь Godot 4+.
2. Делаешь свою игру.
3. Играешь.
Для работы в команде следуешь методам команды.
Godot можно использовать по-разному:
- как внешнюю библиотеку;
- как площадку для своих модулей;
- как конструктор игр из компонентов.
Каждый способ имеет множество вариаций.
В IT нет лучших путей, всегда масса альтернатив.
Ты несмешно шутишь, шути смешнее.
>>30023
>>Я придумал гта 7
>Не думаю, что ты на это способен.
Сириусли? Ты в ГТА вообще играл? Рецепт ГТА:
- реальный город, но урезанный в масштабе;
- тачки и пушки почти как ИРЛ, но аркадные;
- НПЦ ходят по кругу, копы таранят по прямой;
- весь сюжет: "ноунейм пацан к успеху пришёл";
- всё это обильно посыпано шутками про говно.
Тут и придумывать нечего, всё придумали в 90-х.
Алсо, все ГТА полны багов и проблем геймплея.
>>29902
Что такой занятой человек забыл на дваче?
Слишком толстый тролль, попробуй потоньше.
>>29875
>для освоения Godot
Достаточно документации.
>>29884
>нет методологии
Что именно тебе нужно?
Для проекта по фану как хобби в одиночку:
1. Скачиваешь и запускаешь Godot 4+.
2. Делаешь свою игру.
3. Играешь.
Для работы в команде следуешь методам команды.
Godot можно использовать по-разному:
- как внешнюю библиотеку;
- как площадку для своих модулей;
- как конструктор игр из компонентов.
Каждый способ имеет множество вариаций.
В IT нет лучших путей, всегда масса альтернатив.
А вот этому яждизайнеру отдельный ответ:
>>29860
>>30023
Без опыта реализации твоих идей в реальности ты с большой вероятностью придумываешь либо что-то нереализуемое, либо реализуемое, но скучное, либо реализуемое и фановое, но работающее в убыток.
Почему нет реальных воксельных игр? Потому что технически невозможно - все технодемки требуют максимально мощный ПК и очень ограничены, т.е. реализовать "виртуальный мир из атомов" пока что невозможно в том же масштабе, что обычные игры.
Почему опенворлд игры имеют маленький мир и телепортацию? Потому что топать пешком из копии условной Москвы в условный Пекин СКУЧНО, как и виртуально лететь пассажиром на самолёте. Да, мы технически можем Землю в игру сунуть, но зачем?
Почему ММО игры постоянно требуют с игроков непрерывных усилий или вложений денег? Можно реализовать фановую ММО совсем без агрессивной монетизации. Но кто будет платить за сервера? Кто созывать и развлекать игроков? Делать контент?
Некоторые такие нюансы можно понять как игрок, посмотрев на популярные игры. Некоторые можно прочитать в книгах по геймдеву. Но если твоя цель отличается от "сделать клон и нажиться на готовой успешной формуле", свой личный опыт обязателен.
Поэтому грош цена твоим записям, если ты их не реализуешь и даже не пытаешься реализовать.
Лучше художественную литературу пиши. Никто не заставляет вписывать твоих героев в игровой мир, описывая сюжетные арки как квесты для игрока...
>>29860
>Интереснее придумывать чем воплощать
>>30023
>детальное ТЗ со сценарием, геймдизайном
Без опыта реализации твоих идей в реальности ты с большой вероятностью придумываешь либо что-то нереализуемое, либо реализуемое, но скучное, либо реализуемое и фановое, но работающее в убыток.
Почему нет реальных воксельных игр? Потому что технически невозможно - все технодемки требуют максимально мощный ПК и очень ограничены, т.е. реализовать "виртуальный мир из атомов" пока что невозможно в том же масштабе, что обычные игры.
Почему опенворлд игры имеют маленький мир и телепортацию? Потому что топать пешком из копии условной Москвы в условный Пекин СКУЧНО, как и виртуально лететь пассажиром на самолёте. Да, мы технически можем Землю в игру сунуть, но зачем?
Почему ММО игры постоянно требуют с игроков непрерывных усилий или вложений денег? Можно реализовать фановую ММО совсем без агрессивной монетизации. Но кто будет платить за сервера? Кто созывать и развлекать игроков? Делать контент?
Некоторые такие нюансы можно понять как игрок, посмотрев на популярные игры. Некоторые можно прочитать в книгах по геймдеву. Но если твоя цель отличается от "сделать клон и нажиться на готовой успешной формуле", свой личный опыт обязателен.
Поэтому грош цена твоим записям, если ты их не реализуешь и даже не пытаешься реализовать.
Лучше художественную литературу пиши. Никто не заставляет вписывать твоих героев в игровой мир, описывая сюжетные арки как квесты для игрока...
Хочу сохранить исполняемый кусочек кода как значение в словаре, чтобы при загрузке каждый персонаж брал нужный ему набор атак (прыжок, плевок, блок и т.п.) из базы данных. Что-то вроде абилити драфта в доте. В структуризации данных не силён, такой вариант хранения пока лучшее что пришло в голову
Правильно ли я понимаю, что нет разницы между
func jump(args):
#function body
и
var jump : Callable = func(args):
#function body
Чтобы потом запихнуть это в
const MOVE_PATTERNS = {
"jump_attack": jump,
...
}
?
Правильно ли я понимаю, что нет разницы между
func jump(args):
#function body
и
var jump : Callable = func(args):
#function body
Чтобы потом запихнуть это в
const MOVE_PATTERNS = {
"jump_attack": jump,
...
}
?
>>30136
Ты ходишь по очень тонкому льду и в силу глубины своей некомпетентоности не осознаёшь этого.
Нельзя сохранять код как данные. Нельзя мешать код и данные. Нужно различать код и данные. И не сохранять код. Иначе найдётся васян, который засунет вирус туда, где у тебя сохраняется разновидность атаки.
Ты ходишь по очень тонкому льду и в силу глубины своей некомпетентоности не осознаёшь этого.
Нельзя сохранять код как данные. Нельзя мешать код и данные. Нужно различать код и данные. И не сохранять код. Иначе найдётся васян, который засунет вирус туда, где у тебя сохраняется разновидность атаки.
>>30094
Да
>>30103
И что? Профит я имею от других вещей
Скозал как отрезал
>Сириусли?
Да
>>30103
>Без опыта реализации твоих идей в реальности ты с большой вероятностью придумываешь либо что-то нереализуемое, либо реализуемое, но скучное, либо реализуемое и фановое, но работающее в убыток.
И что? Профит я имею от других вещей
>Поэтому грош цена твоим записям
Скозал как отрезал
>>30147
Тоже сначала хотел ему это написать, но он, похоже, планирует что-то другое делать: Callable - это pointer, сохранить (сериализовать) в файл его невозможно.
Загрузка GDScript возможна, но другим способом.
>>30136
Да, разницы нет, можно простые функции юзать.
Анонимные функции нужны только если ты хочешь спрятать их куда-то из поля видимости класса, но необходимости в отдельном классе нет, например:
Здесь ты видишь foo(), а bar спрятан внутри него и передаётся куда-то в foobar() как параметр, т.е. его видимость ограничена функциями foo() и foobar().
Т.е., как я понимаю, ты хочешь сделать так:
1. Сохранить на диск такую запись:
2. Считывать эту запись с диска/из интернета.
3. Заполнять объекты нужными функциями:
Правильно? Должно сработать.
Хотя я бы не использовал JSON для такого, потом замучаешься проверять опечатки в JSON и всё это обновлять одновременно в нескольких местах...
Лучше просто сцены и ресурсы. "The Godot way".
Тоже сначала хотел ему это написать, но он, похоже, планирует что-то другое делать: Callable - это pointer, сохранить (сериализовать) в файл его невозможно.
Загрузка GDScript возможна, но другим способом.
>>30136
>Правильно ли я понимаю, что нет разницы
Да, разницы нет, можно простые функции юзать.
Анонимные функции нужны только если ты хочешь спрятать их куда-то из поля видимости класса, но необходимости в отдельном классе нет, например:
>func foo():
>_ var bar: func(): pass
>_ foobar(bar)
Здесь ты видишь foo(), а bar спрятан внутри него и передаётся куда-то в foobar() как параметр, т.е. его видимость ограничена функциями foo() и foobar().
Т.е., как я понимаю, ты хочешь сделать так:
1. Сохранить на диск такую запись:
>{"frog": {"moves": ["jump", "lick"]},
>"cow": {"moves": ["run", "lick"]},
>"cat": {"moves": ["run", "jump", "lick"]}}
2. Считывать эту запись с диска/из интернета.
3. Заполнять объекты нужными функциями:
>for mob_name in mobs:
>_ var mob := Mob.new(mob_name)
>_ for move_name in mobs[mob_name].moves:
>_ _ mob.add_move(MOVES[move_name])
>_ spawn(mob)
Правильно? Должно сработать.
Хотя я бы не использовал JSON для такого, потом замучаешься проверять опечатки в JSON и всё это обновлять одновременно в нескольких местах...
Лучше просто сцены и ресурсы. "The Godot way".
>>30147
Тоже сначала хотел ему это написать, но он, похоже, планирует что-то другое делать: Callable - это pointer, сохранить (сериализовать) в файл его невозможно.
Загрузка GDScript возможна, но другим способом.
>>30136
Да, разницы нет, можно простые функции юзать.
Анонимные функции нужны только если ты хочешь спрятать их куда-то из поля видимости класса, но необходимости в отдельном классе нет, например:
Здесь ты видишь foo(), а bar спрятан внутри него и передаётся куда-то в foobar() как параметр, т.е. его видимость ограничена функциями foo() и foobar().
Т.е., как я понимаю, ты хочешь сделать так:
1. Сохранить на диск такую запись:
2. Считывать эту запись с диска/из интернета.
3. Заполнять объекты нужными функциями:
Правильно? Должно сработать.
Хотя я бы не использовал JSON для такого, потом замучаешься проверять опечатки в JSON и всё это обновлять одновременно в нескольких местах...
Лучше просто сцены и ресурсы. "The Godot way".
Тоже сначала хотел ему это написать, но он, похоже, планирует что-то другое делать: Callable - это pointer, сохранить (сериализовать) в файл его невозможно.
Загрузка GDScript возможна, но другим способом.
>>30136
>Правильно ли я понимаю, что нет разницы
Да, разницы нет, можно простые функции юзать.
Анонимные функции нужны только если ты хочешь спрятать их куда-то из поля видимости класса, но необходимости в отдельном классе нет, например:
>func foo():
>_ var bar: func(): pass
>_ foobar(bar)
Здесь ты видишь foo(), а bar спрятан внутри него и передаётся куда-то в foobar() как параметр, т.е. его видимость ограничена функциями foo() и foobar().
Т.е., как я понимаю, ты хочешь сделать так:
1. Сохранить на диск такую запись:
>{"frog": {"moves": ["jump", "lick"]},
>"cow": {"moves": ["run", "lick"]},
>"cat": {"moves": ["run", "jump", "lick"]}}
2. Считывать эту запись с диска/из интернета.
3. Заполнять объекты нужными функциями:
>for mob_name in mobs:
>_ var mob := Mob.new(mob_name)
>_ for move_name in mobs[mob_name].moves:
>_ _ mob.add_move(MOVES[move_name])
>_ spawn(mob)
Правильно? Должно сработать.
Хотя я бы не использовал JSON для такого, потом замучаешься проверять опечатки в JSON и всё это обновлять одновременно в нескольких местах...
Лучше просто сцены и ресурсы. "The Godot way".
>>30157
По-моему, нужно использовать keys():
Тогда mob_name будет "frog", "cow", "cat"...
Всё время путаюсь в этом.
>>for mob_name in mobs:
По-моему, нужно использовать keys():
>for mob_name in mobs.keys():
Тогда mob_name будет "frog", "cow", "cat"...
Всё время путаюсь в этом.
>>30157
А, хочу заметить, что можно написать свой Resource, сохраняющий нужные данные в JSON. Тогда будут преимущества JSON - компактность для передачи в интернете - и преимущества Resource - поля видно в инспекторе Godot и Godot сам проверяет типы.
Ещё интересно, что можно объявлять enum:
В Godot 4.4 это должно работать, и очень удобно - в инспекторе появятся списки со всеми значениями.
Чтобы сохранить это в JSON, используй это:
https://docs.godotengine.org/en/stable/classes/class_resourceformatsaver.html
А это - для загрузки:
https://docs.godotengine.org/en/stable/classes/class_resourceformatloader.html
Тогда хранение будет не в tres, а твоём формате.
>замучаешься проверять опечатки в JSON
>Лучше просто сцены и ресурсы
А, хочу заметить, что можно написать свой Resource, сохраняющий нужные данные в JSON. Тогда будут преимущества JSON - компактность для передачи в интернете - и преимущества Resource - поля видно в инспекторе Godot и Godot сам проверяет типы.
Ещё интересно, что можно объявлять enum:
>class_name MobConfig extends Resource
>enum MobType { FROG, COW, CAT }
>enum MoveName { JUMP, RUN, LICK }
>@export var type: MobType
>@export var moves: Array[MoveName]
В Godot 4.4 это должно работать, и очень удобно - в инспекторе появятся списки со всеми значениями.
Чтобы сохранить это в JSON, используй это:
https://docs.godotengine.org/en/stable/classes/class_resourceformatsaver.html
А это - для загрузки:
https://docs.godotengine.org/en/stable/classes/class_resourceformatloader.html
Тогда хранение будет не в tres, а твоём формате.
>>30136
Оберни каждый вид атаки в ноду и дальше комбинируй как угодно. Сохранять можно тупо сцену.
Олсо, разрешать юзверю загружать исполняемый код из файла очень опасно. Вирус подцепит он, а виноват будешь ты. Годот, будучи доверенным приложением, может исполнять абсолютно любой скриптовый код, и ни один антивирус на него не залупнётся.
Оберни каждый вид атаки в ноду и дальше комбинируй как угодно. Сохранять можно тупо сцену.
Олсо, разрешать юзверю загружать исполняемый код из файла очень опасно. Вирус подцепит он, а виноват будешь ты. Годот, будучи доверенным приложением, может исполнять абсолютно любой скриптовый код, и ни один антивирус на него не залупнётся.
>>30175
Обычно не дают прав администратора играм...
Может, ему это нужно для передачи в интернет? Он упомянул базу данных и доту. Кастомные Resource для этого лучше подходят, чем сохранённые сцены.
>будучи доверенным приложением
Обычно не дают прав администратора играм...
>Сохранять можно тупо сцену.
Может, ему это нужно для передачи в интернет? Он упомянул базу данных и доту. Кастомные Resource для этого лучше подходят, чем сохранённые сцены.
>>29753
Там просто много старого кода в разных местах, и приходится внимательно его изучать, чтобы что-то модифицировать без проблем в другом месте.
В общем, вчера я накидал прототип механики как и собирался... Только потом осознал - тестить негде. Подобные механики работают с дизайном уровня, независимо от уровня это делать бессмысленно.
>поподробнее
Там просто много старого кода в разных местах, и приходится внимательно его изучать, чтобы что-то модифицировать без проблем в другом месте.
В общем, вчера я накидал прототип механики как и собирался... Только потом осознал - тестить негде. Подобные механики работают с дизайном уровня, независимо от уровня это делать бессмысленно.
403 Кб, 501x501>>30147
>>30175
Ох, про это я чёто не подумал, спасибо.
>>30157
Задумка была такая:
Скрипт, спавнящий моба, обращается к файлу, который содержит все варианты возможных поведений вообще всех юнитов, и в зависимости от типа моба выбирает оттуда нужные функции типа jump(), deal_damage() и т.п., которые затем передаются в скрипт этого моба, чтобы он пользовался ими в своём _process(). Типа модульная архитектура, чтобы для каждого юнита не прописывать каждый раз одно и то же поведение в разных вариациях
>>30175
Ох, про это я чёто не подумал, спасибо.
>>30157
Задумка была такая:
Скрипт, спавнящий моба, обращается к файлу, который содержит все варианты возможных поведений вообще всех юнитов, и в зависимости от типа моба выбирает оттуда нужные функции типа jump(), deal_damage() и т.п., которые затем передаются в скрипт этого моба, чтобы он пользовался ими в своём _process(). Типа модульная архитектура, чтобы для каждого юнита не прописывать каждый раз одно и то же поведение в разных вариациях
>>30207
Чувак, познакомься с наследованием и переопределением функций в дочерних классах, чтобы не писать такой пиздец. Подучи принципы ооп.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#inheritance
Чувак, познакомься с наследованием и переопределением функций в дочерних классах, чтобы не писать такой пиздец. Подучи принципы ооп.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#inheritance
>>30230
А потом, когда он посзнакомится с наследованием, мы ему сообщим, что наследование в общем-то уже устарело и от него отказываются во всех языках и движках, даже годот предлагает готовую иерархию классов, которую следует применять через композицию в дереве сцены.
Наследование можно применять, но с осторожностью и в его случае гораздо проще использовать композицию. Наделать нод-поведений, дать им имя_класса, далее всё по его тексту с поправкой на компоненты:
>>30207
А потом, когда он посзнакомится с наследованием, мы ему сообщим, что наследование в общем-то уже устарело и от него отказываются во всех языках и движках, даже годот предлагает готовую иерархию классов, которую следует применять через композицию в дереве сцены.
Наследование можно применять, но с осторожностью и в его случае гораздо проще использовать композицию. Наделать нод-поведений, дать им имя_класса, далее всё по его тексту с поправкой на компоненты:
>>30207
> Скрипт, спавнящий моба, обращается к файлу с описанием правил фабрикации моба, который содержит все варианты возможных поведений вообще всех юнитов, и в зависимости от типа моба создаёт ему нужные компоненты типа JumpComponent, DamageComponent и т.п., которые затем добавляются в чайлды этого моба, чтобы они модифицировали поведение моба в своём _process().
>>30232
Во всех это в каких? Не слыхал.
Спасибо, посмеялся. Но есть ньюанс - без внедрения зависимостей этим говном просто невозможно управлять. Чем плохо внедрение можно рассказывать чрезвычайно долго, впрочем кто как хочет так и дрочит, я тебя просто поправил. В краткосрочной инди перспективе, покуда игра не выросла в контент-монстра - можно не использовать нормальные техники управления, не формировать каркас, а обмазываться зависимостями и строить архитектуру через связывание и сигналы, но только в рамках небольших проектов и на краткосрок, за неимением альтернатив.
>от него отказываются во всех языках
Во всех это в каких? Не слыхал.
>гораздо проще использовать композицию
Спасибо, посмеялся. Но есть ньюанс - без внедрения зависимостей этим говном просто невозможно управлять. Чем плохо внедрение можно рассказывать чрезвычайно долго, впрочем кто как хочет так и дрочит, я тебя просто поправил. В краткосрочной инди перспективе, покуда игра не выросла в контент-монстра - можно не использовать нормальные техники управления, не формировать каркас, а обмазываться зависимостями и строить архитектуру через связывание и сигналы, но только в рамках небольших проектов и на краткосрок, за неимением альтернатив.
>>30241
Назови любой - и в нём отказываются.
Впрочем, можешь не называть, здесь тебя не кормят.
> Во всех это в каких?
Назови любой - и в нём отказываются.
> ДИ плохо -> СОЛИД плохо, наследование хорошо, сигналы (ака ивенты, ака сообщения) это связывание и это плохо.
Впрочем, можешь не называть, здесь тебя не кормят.
>>30230
Ну ты дед отсталый, все давно наелись этой каши. Посмеялся с тебя.
>с наследованием и переопределением функций в дочерних классах
Ну ты дед отсталый, все давно наелись этой каши. Посмеялся с тебя.
>>30244
И придумывают ДИ на его место? Шило на мыло называется, еще и без компайлтайма.
Мне важнее чтобы ты до конца договаривал, а то людям пудришь мозг своей композицией, а то вдруг ньюфаг реально поверит в твой изумрудный город.
>>30247
Предпочитаешь кашу поновее, со вкусом смузи-подливы? Я ж не против, главное полный состав ингредиентов указывайте при рекламе.
>Назови любой - и в нём отказываются.
И придумывают ДИ на его место? Шило на мыло называется, еще и без компайлтайма.
>Впрочем, можешь не называть, здесь тебя не кормят.
Мне важнее чтобы ты до конца договаривал, а то людям пудришь мозг своей композицией, а то вдруг ньюфаг реально поверит в твой изумрудный город.
>>30247
>Ну ты дед отсталый, все давно наелись этой каши.
Предпочитаешь кашу поновее, со вкусом смузи-подливы? Я ж не против, главное полный состав ингредиентов указывайте при рекламе.
>>29227
Ну давай начнём с того, что лучший вариант это качнуть Cubase. А рипер это промежуточный вариант. Фрутоподобные высеры это игрушка для детей и хипхоподаунов, у которых музыка это напиздить чужих одних и тех же сэмплов.
Ну давай начнём с того, что лучший вариант это качнуть Cubase. А рипер это промежуточный вариант. Фрутоподобные высеры это игрушка для детей и хипхоподаунов, у которых музыка это напиздить чужих одних и тех же сэмплов.
>>30307
очередной жирный байт безыгорника, это было правдой году в 1999-2000, когда Fruity Loops был простой драм-машинкой
22 года опыта в различных DAW
очередной жирный байт безыгорника, это было правдой году в 1999-2000, когда Fruity Loops был простой драм-машинкой
22 года опыта в различных DAW
Но зато приятно осознавать какие тут деды 40-50 лет сидят. Ламповый тред.
>>30232
Да, так тоже можно, спасибо. Но вопрос по хранению этих компонент: их таки придётся сохранять каждый как отдельную сцену и складывать в отдельной папке, или есть способ спрессовать всё в один скрипт и "на лету" вызывать конструкторы оттуда?
>и в зависимости от типа моба создаёт ему нужные компоненты типа JumpComponent, DamageComponent и т.п., которые затем добавляются в чайлды этого моба
Да, так тоже можно, спасибо. Но вопрос по хранению этих компонент: их таки придётся сохранять каждый как отдельную сцену и складывать в отдельной папке, или есть способ спрессовать всё в один скрипт и "на лету" вызывать конструкторы оттуда?
>>30390
Ну смотри, в итоге в исполняющемся дереве сцены (в рантайме) всё есть ноды. А добавить ноды в дерево существует два классических способа:
1. Создать новый экземпляр конструктором.
2. Создать десериализованный экземпляр из файла.
Так что и твои компоненты ты можешь создать таким же образом. В моём вышепредложенном варианте компоненты это ноды, и они будут в дереве висеть.
Ну смотри, в итоге в исполняющемся дереве сцены (в рантайме) всё есть ноды. А добавить ноды в дерево существует два классических способа:
1. Создать новый экземпляр конструктором.
2. Создать десериализованный экземпляр из файла.
Так что и твои компоненты ты можешь создать таким же образом. В моём вышепредложенном варианте компоненты это ноды, и они будут в дереве висеть.
>>30317
Да какой уж байт, крякнутый фрутилупс это первое что запускает школотун когда решает записать свой рэп в 12 лет. Давай скажи, что это неправда, хочу посмотреть на это.
Не проверял, что они сейчас сделали, чтобы называться DAW, но вангую что к сэмплеру прикрутили дорожки. Наверняка даже на тех дорожках можно напердеть эмбиент в микрофон для своей игры, но это просто смешно для тех людей, кто хочет создавать Музыку.
Да какой уж байт, крякнутый фрутилупс это первое что запускает школотун когда решает записать свой рэп в 12 лет. Давай скажи, что это неправда, хочу посмотреть на это.
Не проверял, что они сейчас сделали, чтобы называться DAW, но вангую что к сэмплеру прикрутили дорожки. Наверняка даже на тех дорожках можно напердеть эмбиент в микрофон для своей игры, но это просто смешно для тех людей, кто хочет создавать Музыку.
>>30410
в 2004 году с релизом fl studio 4.0
алё, дед сейчас этим школотунам лет 30-35
да и начинался fl studio как инструмент для техно - до 4 версии аудиодорожек там не было, следовательно, никакого рэпа
впрочем даже на таких штуках как dream station можно было делать крутые треки, а это ещё до создания стандарта VST
сейчас школотуны запускают garage band, ableton live или на крайний случай studio one
>но вангую что к сэмплеру прикрутили дорожки.
в 2004 году с релизом fl studio 4.0
>что запускает школотун когда решает записать свой рэп в 12 лет
алё, дед сейчас этим школотунам лет 30-35
да и начинался fl studio как инструмент для техно - до 4 версии аудиодорожек там не было, следовательно, никакого рэпа
впрочем даже на таких штуках как dream station можно было делать крутые треки, а это ещё до создания стандарта VST
сейчас школотуны запускают garage band, ableton live или на крайний случай studio one
>>30410
байт на нерелейтед. не кормим.
байт на нерелейтед. не кормим.
>>30207
Они имели в виду ситуацию, когда ты делаешь одно из:
1. Читаешь произвольный .gd скрипт с компа игрока (моды).
2. Скачиваешь произвольный .gd скрипт из интернета (онлайн).
Если ты просто соединяешь свои объекты, то ничего страшного.
Тебе обязательно в одном файле? Запутаешься ведь, что к чему принадлежит. Кроме того, функции сами по себе данные не содержат, а игровое поведение часто связано с хранением и изменением уникальных данных, особенно в контексте персонажей под управлением компьютера (поэтому чисто функциональные языки программирования для геймдева плохо подходят: игры == мутабельность).
Изначально компьютерный код не имел ни функций, ни даже циклов - был только один поток команд и переход на указанный адрес в этом потоке. Но большие программы так делать неудобно из-за того, что рабочая память мозга сильно ограничена, поэтому придумали структуры в коде - циклы, функции, объекты, модули и много чего ещё. Всё это служит одной цели - разделить код на компактные кучки, которые легко прочитать и осмыслить человеческим мозгом, ведь компьютеру это всё безразлично (можешь хоть в Блокноте машинный код писать - компьютер поймёт, но сам ты замучаешься). Как говорится, программист пишет программу для других программистов, а не для компьютера.
Логичным следствием будет разделить код не просто на функции, а на "компоненты", которые в Godot можно представить как потомки Node (дерево сцены, .tscn), Resource (инспектор нод, .tres) или RefCounted (наиболее компактно - прямо в .gd соединять) на твой вкус (использовать чистый Object не рекомендуется, но тоже возможно). Хранить их, разумеется, придётся в отдельных файлах, если это потомки Node или Resource - это ограничение текущего GDScript (есть внутренние классы - которых может быть несколько в одном файле - но они недоступны в дереве сцены и инспекторе). Потомки RefCounted могут быть в одном файле, например:
Соединять будешь как-то так (в том же файле):
Такой подход теоретически эффективнее, чем Node и Resource. Также можно сделать отдельные файлы-коллекции таких классов, обращаться нужно по имени class_name через точку:
В каком-либо другом файле:
Это только один из многих вариантов, всё зависит от тебя.
Но в компонентом подходе к игре есть одно большое "но": если у тебя сейчас нет никакой игры и ты только планируешь замутить сложную систему способностей для сотни разных персонажей а-ля "геройский шутер" или "МОБА", то советую притормозить и не торопиться с декомпозицией всего и вся на компоненты. С большой вероятностью ты сначала убьёшь кучу времени на компоненты, которые невозможно запустить по отдельности (как игру/персонажа), а потом убьёшь кучу времени на правки этих компонентов, когда у тебя появятся сами персонажи и какой-никакой геймплей с ними. Вряд ли ты будешь перемещать компоненты внутри персонажей так же часто, как будешь править код самих этих компонентов, потому что на игру влияет их код в первую очередь, а композиция вторична.
В соло инди геймдеве лучшим подходом будет смастерить играбельный прототип "из говна и палок", лишь бы работал и не крашился, ПОИГРАТЬ в него как следует (выиграть несколько матчей, пройти все уровни несколько раз и т.п.) и оценить свои ощущения от игры, поправить параметры, чтобы улучшить ощущения, и лишь после достижения хороших ощущений начинать рефакторинг получившейся вонючей массы спагетти-кода в нечто расширяемое.
Почему так? Потому что пока ты там теоретизируешь, изобретаешь идеальные компоненты, мечтаешь об идеальной совместимости всех способностей и так далее, в игру ты не играешь и, соответственно, не можешь на практике увидеть, какое же неиграбельное говно ты придумал. В худшем случае ты вообще забудешь, что ты там придумывал, пока пытался сделать все компоненты...
Многие игры проваливаются из-за того, что их делали чистые художники или чистые программисты: они не играли в свою поделку или не думали об игре как об игровом опыте игрока. Они нарисовали идеальный арт или написали идеальный код, а игра оказалась неиграбельным говном, в которое мучительно играть дольше нескольких минут даже целевому игроку-мазохисту.
Также замечу, что в играх крайне редко механики полностью независимы друг от друга: хорошая игра - это комбинация подогнанных друг к другу шестерёнок, действующих друг друга, а не мешок полностью независимых друг от друга игрушек. Нет, разумеется, есть игры-песочницы типа Minecraft, где игроку даётся какой-то набор приколюх (блоки, мобы) и дальше игрок сам находит, чем ему заняться, но даже в таких играх желательно найти баланс механик, чтобы основная масса игроков была довольна. Т.е. разделять вообще всё на универсальные "компоненты" большинству игр просто нет необходимости.
Так что делай игру так, как будет быстрее делаться (по крайней мере, на начальных этапах - до хотя бы первого играбельного прототипа), а не так, как рекомендуют какие-то теоретики в интернете. Лучше быть по колено в говнокоде и говнографике с кучей дефектов, но с играбельной игрой, чем сидеть посреди груды универсальных кубиков Лего и не знать, что хорошего из этих кубиков можно было бы собрать без паяльника и плоскогубцев (т.е. без отказа от универсальности кубиков).
>Ох, про это я чёто не подумал, спасибо.
Они имели в виду ситуацию, когда ты делаешь одно из:
1. Читаешь произвольный .gd скрипт с компа игрока (моды).
2. Скачиваешь произвольный .gd скрипт из интернета (онлайн).
Если ты просто соединяешь свои объекты, то ничего страшного.
>файлу, который содержит все варианты возможных поведений вообще всех юнитов
Тебе обязательно в одном файле? Запутаешься ведь, что к чему принадлежит. Кроме того, функции сами по себе данные не содержат, а игровое поведение часто связано с хранением и изменением уникальных данных, особенно в контексте персонажей под управлением компьютера (поэтому чисто функциональные языки программирования для геймдева плохо подходят: игры == мутабельность).
Изначально компьютерный код не имел ни функций, ни даже циклов - был только один поток команд и переход на указанный адрес в этом потоке. Но большие программы так делать неудобно из-за того, что рабочая память мозга сильно ограничена, поэтому придумали структуры в коде - циклы, функции, объекты, модули и много чего ещё. Всё это служит одной цели - разделить код на компактные кучки, которые легко прочитать и осмыслить человеческим мозгом, ведь компьютеру это всё безразлично (можешь хоть в Блокноте машинный код писать - компьютер поймёт, но сам ты замучаешься). Как говорится, программист пишет программу для других программистов, а не для компьютера.
Логичным следствием будет разделить код не просто на функции, а на "компоненты", которые в Godot можно представить как потомки Node (дерево сцены, .tscn), Resource (инспектор нод, .tres) или RefCounted (наиболее компактно - прямо в .gd соединять) на твой вкус (использовать чистый Object не рекомендуется, но тоже возможно). Хранить их, разумеется, придётся в отдельных файлах, если это потомки Node или Resource - это ограничение текущего GDScript (есть внутренние классы - которых может быть несколько в одном файле - но они недоступны в дереве сцены и инспекторе). Потомки RefCounted могут быть в одном файле, например:
>class Component: # автоматически становится потомком RefCounted
>_ pass # что-то общее для всех компонентов
>class RunComponent extends Component:
>_ func run() -> void: pass
Соединять будешь как-то так (в том же файле):
>var components: Array[Component]
>func _ready() -> void:
>_ components.append(RunComponent.new())
Такой подход теоретически эффективнее, чем Node и Resource. Также можно сделать отдельные файлы-коллекции таких классов, обращаться нужно по имени class_name через точку:
>class_name Components extends RefCounted # тут предок не важен, только имя
>class Component: pass # предок - RefCounted
>class RunComponent extends Component: pass
>class JumpComponent extends Component: pass
В каком-либо другом файле:
>var components: Array[Components.Component] # должно работать, но без @export
>Components.RunComponent.new()
>Components.JumpComponent.new()
Это только один из многих вариантов, всё зависит от тебя.
Но в компонентом подходе к игре есть одно большое "но": если у тебя сейчас нет никакой игры и ты только планируешь замутить сложную систему способностей для сотни разных персонажей а-ля "геройский шутер" или "МОБА", то советую притормозить и не торопиться с декомпозицией всего и вся на компоненты. С большой вероятностью ты сначала убьёшь кучу времени на компоненты, которые невозможно запустить по отдельности (как игру/персонажа), а потом убьёшь кучу времени на правки этих компонентов, когда у тебя появятся сами персонажи и какой-никакой геймплей с ними. Вряд ли ты будешь перемещать компоненты внутри персонажей так же часто, как будешь править код самих этих компонентов, потому что на игру влияет их код в первую очередь, а композиция вторична.
В соло инди геймдеве лучшим подходом будет смастерить играбельный прототип "из говна и палок", лишь бы работал и не крашился, ПОИГРАТЬ в него как следует (выиграть несколько матчей, пройти все уровни несколько раз и т.п.) и оценить свои ощущения от игры, поправить параметры, чтобы улучшить ощущения, и лишь после достижения хороших ощущений начинать рефакторинг получившейся вонючей массы спагетти-кода в нечто расширяемое.
Почему так? Потому что пока ты там теоретизируешь, изобретаешь идеальные компоненты, мечтаешь об идеальной совместимости всех способностей и так далее, в игру ты не играешь и, соответственно, не можешь на практике увидеть, какое же неиграбельное говно ты придумал. В худшем случае ты вообще забудешь, что ты там придумывал, пока пытался сделать все компоненты...
Многие игры проваливаются из-за того, что их делали чистые художники или чистые программисты: они не играли в свою поделку или не думали об игре как об игровом опыте игрока. Они нарисовали идеальный арт или написали идеальный код, а игра оказалась неиграбельным говном, в которое мучительно играть дольше нескольких минут даже целевому игроку-мазохисту.
Также замечу, что в играх крайне редко механики полностью независимы друг от друга: хорошая игра - это комбинация подогнанных друг к другу шестерёнок, действующих друг друга, а не мешок полностью независимых друг от друга игрушек. Нет, разумеется, есть игры-песочницы типа Minecraft, где игроку даётся какой-то набор приколюх (блоки, мобы) и дальше игрок сам находит, чем ему заняться, но даже в таких играх желательно найти баланс механик, чтобы основная масса игроков была довольна. Т.е. разделять вообще всё на универсальные "компоненты" большинству игр просто нет необходимости.
Так что делай игру так, как будет быстрее делаться (по крайней мере, на начальных этапах - до хотя бы первого играбельного прототипа), а не так, как рекомендуют какие-то теоретики в интернете. Лучше быть по колено в говнокоде и говнографике с кучей дефектов, но с играбельной игрой, чем сидеть посреди груды универсальных кубиков Лего и не знать, что хорошего из этих кубиков можно было бы собрать без паяльника и плоскогубцев (т.е. без отказа от универсальности кубиков).
>>30207
Они имели в виду ситуацию, когда ты делаешь одно из:
1. Читаешь произвольный .gd скрипт с компа игрока (моды).
2. Скачиваешь произвольный .gd скрипт из интернета (онлайн).
Если ты просто соединяешь свои объекты, то ничего страшного.
Тебе обязательно в одном файле? Запутаешься ведь, что к чему принадлежит. Кроме того, функции сами по себе данные не содержат, а игровое поведение часто связано с хранением и изменением уникальных данных, особенно в контексте персонажей под управлением компьютера (поэтому чисто функциональные языки программирования для геймдева плохо подходят: игры == мутабельность).
Изначально компьютерный код не имел ни функций, ни даже циклов - был только один поток команд и переход на указанный адрес в этом потоке. Но большие программы так делать неудобно из-за того, что рабочая память мозга сильно ограничена, поэтому придумали структуры в коде - циклы, функции, объекты, модули и много чего ещё. Всё это служит одной цели - разделить код на компактные кучки, которые легко прочитать и осмыслить человеческим мозгом, ведь компьютеру это всё безразлично (можешь хоть в Блокноте машинный код писать - компьютер поймёт, но сам ты замучаешься). Как говорится, программист пишет программу для других программистов, а не для компьютера.
Логичным следствием будет разделить код не просто на функции, а на "компоненты", которые в Godot можно представить как потомки Node (дерево сцены, .tscn), Resource (инспектор нод, .tres) или RefCounted (наиболее компактно - прямо в .gd соединять) на твой вкус (использовать чистый Object не рекомендуется, но тоже возможно). Хранить их, разумеется, придётся в отдельных файлах, если это потомки Node или Resource - это ограничение текущего GDScript (есть внутренние классы - которых может быть несколько в одном файле - но они недоступны в дереве сцены и инспекторе). Потомки RefCounted могут быть в одном файле, например:
Соединять будешь как-то так (в том же файле):
Такой подход теоретически эффективнее, чем Node и Resource. Также можно сделать отдельные файлы-коллекции таких классов, обращаться нужно по имени class_name через точку:
В каком-либо другом файле:
Это только один из многих вариантов, всё зависит от тебя.
Но в компонентом подходе к игре есть одно большое "но": если у тебя сейчас нет никакой игры и ты только планируешь замутить сложную систему способностей для сотни разных персонажей а-ля "геройский шутер" или "МОБА", то советую притормозить и не торопиться с декомпозицией всего и вся на компоненты. С большой вероятностью ты сначала убьёшь кучу времени на компоненты, которые невозможно запустить по отдельности (как игру/персонажа), а потом убьёшь кучу времени на правки этих компонентов, когда у тебя появятся сами персонажи и какой-никакой геймплей с ними. Вряд ли ты будешь перемещать компоненты внутри персонажей так же часто, как будешь править код самих этих компонентов, потому что на игру влияет их код в первую очередь, а композиция вторична.
В соло инди геймдеве лучшим подходом будет смастерить играбельный прототип "из говна и палок", лишь бы работал и не крашился, ПОИГРАТЬ в него как следует (выиграть несколько матчей, пройти все уровни несколько раз и т.п.) и оценить свои ощущения от игры, поправить параметры, чтобы улучшить ощущения, и лишь после достижения хороших ощущений начинать рефакторинг получившейся вонючей массы спагетти-кода в нечто расширяемое.
Почему так? Потому что пока ты там теоретизируешь, изобретаешь идеальные компоненты, мечтаешь об идеальной совместимости всех способностей и так далее, в игру ты не играешь и, соответственно, не можешь на практике увидеть, какое же неиграбельное говно ты придумал. В худшем случае ты вообще забудешь, что ты там придумывал, пока пытался сделать все компоненты...
Многие игры проваливаются из-за того, что их делали чистые художники или чистые программисты: они не играли в свою поделку или не думали об игре как об игровом опыте игрока. Они нарисовали идеальный арт или написали идеальный код, а игра оказалась неиграбельным говном, в которое мучительно играть дольше нескольких минут даже целевому игроку-мазохисту.
Также замечу, что в играх крайне редко механики полностью независимы друг от друга: хорошая игра - это комбинация подогнанных друг к другу шестерёнок, действующих друг друга, а не мешок полностью независимых друг от друга игрушек. Нет, разумеется, есть игры-песочницы типа Minecraft, где игроку даётся какой-то набор приколюх (блоки, мобы) и дальше игрок сам находит, чем ему заняться, но даже в таких играх желательно найти баланс механик, чтобы основная масса игроков была довольна. Т.е. разделять вообще всё на универсальные "компоненты" большинству игр просто нет необходимости.
Так что делай игру так, как будет быстрее делаться (по крайней мере, на начальных этапах - до хотя бы первого играбельного прототипа), а не так, как рекомендуют какие-то теоретики в интернете. Лучше быть по колено в говнокоде и говнографике с кучей дефектов, но с играбельной игрой, чем сидеть посреди груды универсальных кубиков Лего и не знать, что хорошего из этих кубиков можно было бы собрать без паяльника и плоскогубцев (т.е. без отказа от универсальности кубиков).
>Ох, про это я чёто не подумал, спасибо.
Они имели в виду ситуацию, когда ты делаешь одно из:
1. Читаешь произвольный .gd скрипт с компа игрока (моды).
2. Скачиваешь произвольный .gd скрипт из интернета (онлайн).
Если ты просто соединяешь свои объекты, то ничего страшного.
>файлу, который содержит все варианты возможных поведений вообще всех юнитов
Тебе обязательно в одном файле? Запутаешься ведь, что к чему принадлежит. Кроме того, функции сами по себе данные не содержат, а игровое поведение часто связано с хранением и изменением уникальных данных, особенно в контексте персонажей под управлением компьютера (поэтому чисто функциональные языки программирования для геймдева плохо подходят: игры == мутабельность).
Изначально компьютерный код не имел ни функций, ни даже циклов - был только один поток команд и переход на указанный адрес в этом потоке. Но большие программы так делать неудобно из-за того, что рабочая память мозга сильно ограничена, поэтому придумали структуры в коде - циклы, функции, объекты, модули и много чего ещё. Всё это служит одной цели - разделить код на компактные кучки, которые легко прочитать и осмыслить человеческим мозгом, ведь компьютеру это всё безразлично (можешь хоть в Блокноте машинный код писать - компьютер поймёт, но сам ты замучаешься). Как говорится, программист пишет программу для других программистов, а не для компьютера.
Логичным следствием будет разделить код не просто на функции, а на "компоненты", которые в Godot можно представить как потомки Node (дерево сцены, .tscn), Resource (инспектор нод, .tres) или RefCounted (наиболее компактно - прямо в .gd соединять) на твой вкус (использовать чистый Object не рекомендуется, но тоже возможно). Хранить их, разумеется, придётся в отдельных файлах, если это потомки Node или Resource - это ограничение текущего GDScript (есть внутренние классы - которых может быть несколько в одном файле - но они недоступны в дереве сцены и инспекторе). Потомки RefCounted могут быть в одном файле, например:
>class Component: # автоматически становится потомком RefCounted
>_ pass # что-то общее для всех компонентов
>class RunComponent extends Component:
>_ func run() -> void: pass
Соединять будешь как-то так (в том же файле):
>var components: Array[Component]
>func _ready() -> void:
>_ components.append(RunComponent.new())
Такой подход теоретически эффективнее, чем Node и Resource. Также можно сделать отдельные файлы-коллекции таких классов, обращаться нужно по имени class_name через точку:
>class_name Components extends RefCounted # тут предок не важен, только имя
>class Component: pass # предок - RefCounted
>class RunComponent extends Component: pass
>class JumpComponent extends Component: pass
В каком-либо другом файле:
>var components: Array[Components.Component] # должно работать, но без @export
>Components.RunComponent.new()
>Components.JumpComponent.new()
Это только один из многих вариантов, всё зависит от тебя.
Но в компонентом подходе к игре есть одно большое "но": если у тебя сейчас нет никакой игры и ты только планируешь замутить сложную систему способностей для сотни разных персонажей а-ля "геройский шутер" или "МОБА", то советую притормозить и не торопиться с декомпозицией всего и вся на компоненты. С большой вероятностью ты сначала убьёшь кучу времени на компоненты, которые невозможно запустить по отдельности (как игру/персонажа), а потом убьёшь кучу времени на правки этих компонентов, когда у тебя появятся сами персонажи и какой-никакой геймплей с ними. Вряд ли ты будешь перемещать компоненты внутри персонажей так же часто, как будешь править код самих этих компонентов, потому что на игру влияет их код в первую очередь, а композиция вторична.
В соло инди геймдеве лучшим подходом будет смастерить играбельный прототип "из говна и палок", лишь бы работал и не крашился, ПОИГРАТЬ в него как следует (выиграть несколько матчей, пройти все уровни несколько раз и т.п.) и оценить свои ощущения от игры, поправить параметры, чтобы улучшить ощущения, и лишь после достижения хороших ощущений начинать рефакторинг получившейся вонючей массы спагетти-кода в нечто расширяемое.
Почему так? Потому что пока ты там теоретизируешь, изобретаешь идеальные компоненты, мечтаешь об идеальной совместимости всех способностей и так далее, в игру ты не играешь и, соответственно, не можешь на практике увидеть, какое же неиграбельное говно ты придумал. В худшем случае ты вообще забудешь, что ты там придумывал, пока пытался сделать все компоненты...
Многие игры проваливаются из-за того, что их делали чистые художники или чистые программисты: они не играли в свою поделку или не думали об игре как об игровом опыте игрока. Они нарисовали идеальный арт или написали идеальный код, а игра оказалась неиграбельным говном, в которое мучительно играть дольше нескольких минут даже целевому игроку-мазохисту.
Также замечу, что в играх крайне редко механики полностью независимы друг от друга: хорошая игра - это комбинация подогнанных друг к другу шестерёнок, действующих друг друга, а не мешок полностью независимых друг от друга игрушек. Нет, разумеется, есть игры-песочницы типа Minecraft, где игроку даётся какой-то набор приколюх (блоки, мобы) и дальше игрок сам находит, чем ему заняться, но даже в таких играх желательно найти баланс механик, чтобы основная масса игроков была довольна. Т.е. разделять вообще всё на универсальные "компоненты" большинству игр просто нет необходимости.
Так что делай игру так, как будет быстрее делаться (по крайней мере, на начальных этапах - до хотя бы первого играбельного прототипа), а не так, как рекомендуют какие-то теоретики в интернете. Лучше быть по колено в говнокоде и говнографике с кучей дефектов, но с играбельной игрой, чем сидеть посреди груды универсальных кубиков Лего и не знать, что хорошего из этих кубиков можно было бы собрать без паяльника и плоскогубцев (т.е. без отказа от универсальности кубиков).
Держи видос в тему.
https://www.youtube.com/watch?v=PYHgvXqOSo4
https://www.youtube.com/watch?v=PYHgvXqOSo4
>>30455
Дебилоиды, ООП в геймдеве это полная параша. Нахуя вы этим занимаетесь когда есть ESC?
Дебилоиды, ООП в геймдеве это полная параша. Нахуя вы этим занимаетесь когда есть ESC?
>>30458
А игру мне кто будет делать на ECS?
>>30455
Ютуб заблокирован и видео нинужно, вот проект из видео:
https://github.com/jacobfoxe/Composition-Demo-Godot-4
>вы этим занимаетесь когда есть ESC?
А игру мне кто будет делать на ECS?
>>30455
Ютуб заблокирован и видео нинужно, вот проект из видео:
https://github.com/jacobfoxe/Composition-Demo-Godot-4
552 Кб, 1400x700>я делаю
281 Кб, 1593x848>>30499
Только если ты любитель наплодить мусор в игре и в системе. Хотя если твоя игра сама по себе мусор, то тогда наверное похую.
Только если ты любитель наплодить мусор в игре и в системе. Хотя если твоя игра сама по себе мусор, то тогда наверное похую.
А можно на годоте 100к инстансов со 120 фпс плиз?
https://youtu.be/RiKPrOx2jmE
https://youtu.be/RiKPrOx2jmE
>>29227
Ну хуй знает, как по мне, у рипака ужасно не интуитивный интерфейс. Но я уже много лет гоняю Ardour, и мне его интерфейс кажется простым и логичным, а я знаю, что для многих это не так.
Олсо, LMMS - отличный выбор для начинающего звукодела, потому что:
1. Имеет кучу встроенных инструментов с кучей встроенных звуков;
2. Сконцентрирован на паттернах - удобен для вкатунов в музыку;
3. (на линуксе) Работает на пульсаудио, не требует JACK (впрочем, современные дистры переходят на pipewire, так что это постепенно теряет актуальность)
И ещё осмелюсь заявить, что LMMS софтина могучая, и электронные композиции на ней можно делать на профессиональном уровне. Но с другой стороны - плохая поддержка плагинов и мелкий интерфейс.
>DAW что бы звуки делать, а не что бы мануалы по ней читать.
>Reaper
Ну хуй знает, как по мне, у рипака ужасно не интуитивный интерфейс. Но я уже много лет гоняю Ardour, и мне его интерфейс кажется простым и логичным, а я знаю, что для многих это не так.
Олсо, LMMS - отличный выбор для начинающего звукодела, потому что:
1. Имеет кучу встроенных инструментов с кучей встроенных звуков;
2. Сконцентрирован на паттернах - удобен для вкатунов в музыку;
3. (на линуксе) Работает на пульсаудио, не требует JACK (впрочем, современные дистры переходят на pipewire, так что это постепенно теряет актуальность)
И ещё осмелюсь заявить, что LMMS софтина могучая, и электронные композиции на ней можно делать на профессиональном уровне. Но с другой стороны - плохая поддержка плагинов и мелкий интерфейс.
>>30539
Конечно. Выкидывай гдс с шарпами, выкидывай физику и пиши игру как часть движк на плюсах. Будет то же самое.
Конечно. Выкидывай гдс с шарпами, выкидывай физику и пиши игру как часть движк на плюсах. Будет то же самое.
>>30543
Я поддерживаю опенсорс обеими руками, но как ноускиллз в музыке единственный DAW который я хоть как-то осилил - bandlab. Он под веб и могилки. Может еще Bosca Ceoil глянуть стоит. Но лень.
Я поддерживаю опенсорс обеими руками, но как ноускиллз в музыке единственный DAW который я хоть как-то осилил - bandlab. Он под веб и могилки. Может еще Bosca Ceoil глянуть стоит. Но лень.
>>30536
Во-первых, никто тебе не запрещает в ООП использовать DOD через SoA. Во-вторых, если говорить о каких-то быстрых реализациях, то на С++ компилятор заточен на оптимизацию ООП кода по цепочкам ссылок, в ЕЦС он запутается и выдаст медленный код. В-третьих, твой пик говорит о вырожденном случае для бенчмарков из однотипных объектов, в реальности такого не встречается. Так что да, ЕЦС подходит только для мусора. Ну там если у тебя в игре генерится мусор по сто тысяч объектов.
Во-первых, никто тебе не запрещает в ООП использовать DOD через SoA. Во-вторых, если говорить о каких-то быстрых реализациях, то на С++ компилятор заточен на оптимизацию ООП кода по цепочкам ссылок, в ЕЦС он запутается и выдаст медленный код. В-третьих, твой пик говорит о вырожденном случае для бенчмарков из однотипных объектов, в реальности такого не встречается. Так что да, ЕЦС подходит только для мусора. Ну там если у тебя в игре генерится мусор по сто тысяч объектов.
>>30539
А можно вылечить твой склероз? На годоте 3.5 пять лет назад
https://www.youtube.com/watch?v=HawWnuMn1mc
А можно вылечить твой склероз? На годоте 3.5 пять лет назад
https://www.youtube.com/watch?v=HawWnuMn1mc
>>30536
Overwatch на ECS. Чем им это помогло? У них максимум 12 героев в матче, лол, а потом и вовсе урезали до 10, но репутацию это не спасло. Даже пули у них не моделируются подробно (хитскан как в древнейших шутанах из 90-х), а физические снаряды у очень небольшого числа героев и сильно ограничены по количеству одновременных выстрелов. Ещё и карты в матчах максимально статичные, даже банальных разбиваемых ящиков нет, ты просто топаешь и стреляешь в героев, вот и весь геймплей. Сюжетку они несколько лет делали и в итоге отменили, потому что не получилось сделать, а новых героев они долго не добавляли - почему? ECS мешала?
Тем временем PlanetSide 2 - классическая ООП лапша - поддерживает до двух тысяч игроков в одном бесшовном мире (сервере), где регулярно происходят сражения на сто человек. Разные виды физического транспорта, управляемого игроками, захват территории - всё как мы, ООПышки, любим - никакого ECS маразма, лишь чистый ООП фан.
Делайте выводы.
Overwatch на ECS. Чем им это помогло? У них максимум 12 героев в матче, лол, а потом и вовсе урезали до 10, но репутацию это не спасло. Даже пули у них не моделируются подробно (хитскан как в древнейших шутанах из 90-х), а физические снаряды у очень небольшого числа героев и сильно ограничены по количеству одновременных выстрелов. Ещё и карты в матчах максимально статичные, даже банальных разбиваемых ящиков нет, ты просто топаешь и стреляешь в героев, вот и весь геймплей. Сюжетку они несколько лет делали и в итоге отменили, потому что не получилось сделать, а новых героев они долго не добавляли - почему? ECS мешала?
Тем временем PlanetSide 2 - классическая ООП лапша - поддерживает до двух тысяч игроков в одном бесшовном мире (сервере), где регулярно происходят сражения на сто человек. Разные виды физического транспорта, управляемого игроками, захват территории - всё как мы, ООПышки, любим - никакого ECS маразма, лишь чистый ООП фан.
Делайте выводы.
81 Кб, 999x666>>30455
Видео не смотрел, но посмотрел (поверхностно) проект: >>30471
Мой вердикт: не рекомендую на это ориентироваться.
Во-первых, эта демка - не игра. По крайней мере в ней нет ничего сложного, что помогло бы доказать или наглядно продемонстрировать преимущества выбранного подхода/архитектуры. Там всего 2 сущности - бездействующий NPC и игрок, и весь "геймплей" состоит из нажатия пары-тройки клавиш. Если хотите доказать что-то в геймдеве и показать новичкам, как надо - делайте полноценную игру. Сейчас это выглядит так: "я ниасилил использовать свой же собственный метод, которому учу".
Во-вторых, там куча лишних нод в дереве, куча дублирующегося кода и вообще куча всего, в чём сложно разобраться. Данную тривиальную "игру" можно было бы сделать буквально за несколько строчек кода, не делая несколько портянок в разных папках. Вчитываться в это и пытаться распутать клубок зависимостей желания нет. Сложность архитектуры должна соответствовать амбициям проекта, и раз вся игра состоит из движения одного спрайта к другому, развешивать такие портянки было не нужно.
В-третьих, там не соблюдаются установленные Godot соглашения по именованию (naming convention) и форматированию кода. Выглядит так, что это писал кто-то, не знакомый с Godot, и пытающийся адаптировать что-то чужеродное к Godot. Впрочем, кто в своём здравом уме будет давать имена классам КАПСЛОКОМ? С какого языка программирования он переходит, где это норма? С Бейсика? Пусть сначала выучит соглашения по именованию, а потом уже учит новичков сложным ООП концептам.
Любую игру можно сделать любым способом - всё зависит от навыков разработчика, привычки и субъективных предпочтений. Воспринимать такие "демки" как истину в последней инстанции нельзя, а у новичков как правило установка на копирование туториального кода в свой проект и попытки сделать из него игру. Поэтому я считаю подобные недоделанные проекты вредными или даже опасными для новичков.
Анон, старайся сам внимательно просматривать то, чем делишься в треде. Рандомные ссылки на рандомные уроки с рандомного канала на ютубе аноны в треде и сами смогут найти в поисковике; двач - это форум, а не коллекция рандомных ссылок.
Стрелки на скриншоте показывают абстрактную логику взаимодействия (кто на что должен, по идее, влиять), а не то, что там в коде происходит. Признаться честно - я не вчитывался и не собираюсь вчитываться. Но "editable children" в основной сцене там было включено автором демки - потому что ему пришлось вставлять какие-то ноды в поля этих вложенных нод-"модулей", видимо, чтобы заставить всё работать. Это серьёзный косяк архитектуры проекта, т.к. "editable children" не рекомендуется использовать так часто (это костыль и он часто неожиданно ломается). Если вам нужно соединить две сцены внутри третьей сцены, экспортируйте ноды в корневой ноде этих двух сцен, не используя "editable children" без крайней необходимости. Для сравнения, "editable children" в Godot - это как вызывать приватный метод ООП класса из какого-то другого, совершенно независимого класса (очень плохо).
Хотел ещё вчера ночью этот пост написать, но двач упал и лежал несколько часов...
Видео не смотрел, но посмотрел (поверхностно) проект: >>30471
Мой вердикт: не рекомендую на это ориентироваться.
Во-первых, эта демка - не игра. По крайней мере в ней нет ничего сложного, что помогло бы доказать или наглядно продемонстрировать преимущества выбранного подхода/архитектуры. Там всего 2 сущности - бездействующий NPC и игрок, и весь "геймплей" состоит из нажатия пары-тройки клавиш. Если хотите доказать что-то в геймдеве и показать новичкам, как надо - делайте полноценную игру. Сейчас это выглядит так: "я ниасилил использовать свой же собственный метод, которому учу".
Во-вторых, там куча лишних нод в дереве, куча дублирующегося кода и вообще куча всего, в чём сложно разобраться. Данную тривиальную "игру" можно было бы сделать буквально за несколько строчек кода, не делая несколько портянок в разных папках. Вчитываться в это и пытаться распутать клубок зависимостей желания нет. Сложность архитектуры должна соответствовать амбициям проекта, и раз вся игра состоит из движения одного спрайта к другому, развешивать такие портянки было не нужно.
В-третьих, там не соблюдаются установленные Godot соглашения по именованию (naming convention) и форматированию кода. Выглядит так, что это писал кто-то, не знакомый с Godot, и пытающийся адаптировать что-то чужеродное к Godot. Впрочем, кто в своём здравом уме будет давать имена классам КАПСЛОКОМ? С какого языка программирования он переходит, где это норма? С Бейсика? Пусть сначала выучит соглашения по именованию, а потом уже учит новичков сложным ООП концептам.
Любую игру можно сделать любым способом - всё зависит от навыков разработчика, привычки и субъективных предпочтений. Воспринимать такие "демки" как истину в последней инстанции нельзя, а у новичков как правило установка на копирование туториального кода в свой проект и попытки сделать из него игру. Поэтому я считаю подобные недоделанные проекты вредными или даже опасными для новичков.
Анон, старайся сам внимательно просматривать то, чем делишься в треде. Рандомные ссылки на рандомные уроки с рандомного канала на ютубе аноны в треде и сами смогут найти в поисковике; двач - это форум, а не коллекция рандомных ссылок.
Стрелки на скриншоте показывают абстрактную логику взаимодействия (кто на что должен, по идее, влиять), а не то, что там в коде происходит. Признаться честно - я не вчитывался и не собираюсь вчитываться. Но "editable children" в основной сцене там было включено автором демки - потому что ему пришлось вставлять какие-то ноды в поля этих вложенных нод-"модулей", видимо, чтобы заставить всё работать. Это серьёзный косяк архитектуры проекта, т.к. "editable children" не рекомендуется использовать так часто (это костыль и он часто неожиданно ломается). Если вам нужно соединить две сцены внутри третьей сцены, экспортируйте ноды в корневой ноде этих двух сцен, не используя "editable children" без крайней необходимости. Для сравнения, "editable children" в Godot - это как вызывать приватный метод ООП класса из какого-то другого, совершенно независимого класса (очень плохо).
Хотел ещё вчера ночью этот пост написать, но двач упал и лежал несколько часов...
81 Кб, 999x666>>30455
Видео не смотрел, но посмотрел (поверхностно) проект: >>30471
Мой вердикт: не рекомендую на это ориентироваться.
Во-первых, эта демка - не игра. По крайней мере в ней нет ничего сложного, что помогло бы доказать или наглядно продемонстрировать преимущества выбранного подхода/архитектуры. Там всего 2 сущности - бездействующий NPC и игрок, и весь "геймплей" состоит из нажатия пары-тройки клавиш. Если хотите доказать что-то в геймдеве и показать новичкам, как надо - делайте полноценную игру. Сейчас это выглядит так: "я ниасилил использовать свой же собственный метод, которому учу".
Во-вторых, там куча лишних нод в дереве, куча дублирующегося кода и вообще куча всего, в чём сложно разобраться. Данную тривиальную "игру" можно было бы сделать буквально за несколько строчек кода, не делая несколько портянок в разных папках. Вчитываться в это и пытаться распутать клубок зависимостей желания нет. Сложность архитектуры должна соответствовать амбициям проекта, и раз вся игра состоит из движения одного спрайта к другому, развешивать такие портянки было не нужно.
В-третьих, там не соблюдаются установленные Godot соглашения по именованию (naming convention) и форматированию кода. Выглядит так, что это писал кто-то, не знакомый с Godot, и пытающийся адаптировать что-то чужеродное к Godot. Впрочем, кто в своём здравом уме будет давать имена классам КАПСЛОКОМ? С какого языка программирования он переходит, где это норма? С Бейсика? Пусть сначала выучит соглашения по именованию, а потом уже учит новичков сложным ООП концептам.
Любую игру можно сделать любым способом - всё зависит от навыков разработчика, привычки и субъективных предпочтений. Воспринимать такие "демки" как истину в последней инстанции нельзя, а у новичков как правило установка на копирование туториального кода в свой проект и попытки сделать из него игру. Поэтому я считаю подобные недоделанные проекты вредными или даже опасными для новичков.
Анон, старайся сам внимательно просматривать то, чем делишься в треде. Рандомные ссылки на рандомные уроки с рандомного канала на ютубе аноны в треде и сами смогут найти в поисковике; двач - это форум, а не коллекция рандомных ссылок.
Стрелки на скриншоте показывают абстрактную логику взаимодействия (кто на что должен, по идее, влиять), а не то, что там в коде происходит. Признаться честно - я не вчитывался и не собираюсь вчитываться. Но "editable children" в основной сцене там было включено автором демки - потому что ему пришлось вставлять какие-то ноды в поля этих вложенных нод-"модулей", видимо, чтобы заставить всё работать. Это серьёзный косяк архитектуры проекта, т.к. "editable children" не рекомендуется использовать так часто (это костыль и он часто неожиданно ломается). Если вам нужно соединить две сцены внутри третьей сцены, экспортируйте ноды в корневой ноде этих двух сцен, не используя "editable children" без крайней необходимости. Для сравнения, "editable children" в Godot - это как вызывать приватный метод ООП класса из какого-то другого, совершенно независимого класса (очень плохо).
Хотел ещё вчера ночью этот пост написать, но двач упал и лежал несколько часов...
Видео не смотрел, но посмотрел (поверхностно) проект: >>30471
Мой вердикт: не рекомендую на это ориентироваться.
Во-первых, эта демка - не игра. По крайней мере в ней нет ничего сложного, что помогло бы доказать или наглядно продемонстрировать преимущества выбранного подхода/архитектуры. Там всего 2 сущности - бездействующий NPC и игрок, и весь "геймплей" состоит из нажатия пары-тройки клавиш. Если хотите доказать что-то в геймдеве и показать новичкам, как надо - делайте полноценную игру. Сейчас это выглядит так: "я ниасилил использовать свой же собственный метод, которому учу".
Во-вторых, там куча лишних нод в дереве, куча дублирующегося кода и вообще куча всего, в чём сложно разобраться. Данную тривиальную "игру" можно было бы сделать буквально за несколько строчек кода, не делая несколько портянок в разных папках. Вчитываться в это и пытаться распутать клубок зависимостей желания нет. Сложность архитектуры должна соответствовать амбициям проекта, и раз вся игра состоит из движения одного спрайта к другому, развешивать такие портянки было не нужно.
В-третьих, там не соблюдаются установленные Godot соглашения по именованию (naming convention) и форматированию кода. Выглядит так, что это писал кто-то, не знакомый с Godot, и пытающийся адаптировать что-то чужеродное к Godot. Впрочем, кто в своём здравом уме будет давать имена классам КАПСЛОКОМ? С какого языка программирования он переходит, где это норма? С Бейсика? Пусть сначала выучит соглашения по именованию, а потом уже учит новичков сложным ООП концептам.
Любую игру можно сделать любым способом - всё зависит от навыков разработчика, привычки и субъективных предпочтений. Воспринимать такие "демки" как истину в последней инстанции нельзя, а у новичков как правило установка на копирование туториального кода в свой проект и попытки сделать из него игру. Поэтому я считаю подобные недоделанные проекты вредными или даже опасными для новичков.
Анон, старайся сам внимательно просматривать то, чем делишься в треде. Рандомные ссылки на рандомные уроки с рандомного канала на ютубе аноны в треде и сами смогут найти в поисковике; двач - это форум, а не коллекция рандомных ссылок.
Стрелки на скриншоте показывают абстрактную логику взаимодействия (кто на что должен, по идее, влиять), а не то, что там в коде происходит. Признаться честно - я не вчитывался и не собираюсь вчитываться. Но "editable children" в основной сцене там было включено автором демки - потому что ему пришлось вставлять какие-то ноды в поля этих вложенных нод-"модулей", видимо, чтобы заставить всё работать. Это серьёзный косяк архитектуры проекта, т.к. "editable children" не рекомендуется использовать так часто (это костыль и он часто неожиданно ломается). Если вам нужно соединить две сцены внутри третьей сцены, экспортируйте ноды в корневой ноде этих двух сцен, не используя "editable children" без крайней необходимости. Для сравнения, "editable children" в Godot - это как вызывать приватный метод ООП класса из какого-то другого, совершенно независимого класса (очень плохо).
Хотел ещё вчера ночью этот пост написать, но двач упал и лежал несколько часов...
>>30680
Спасибо. Вносим афтора в чорный список.
Спасибо. Вносим афтора в чорный список.
>>30668
Он только визуально бесшовный, а сражения 100 на 100 происходят в 20 FPS и с регистрацией попаданий в 2000 мсек когда ты умираешь и видишь уже после смерти как в тебя стреяют потому, что сервер помирает на синхронизации.
В любом случает ECS это не противоположность ООП, это просто разные подходы и вроде есть даже их гибриды, и нужно уметь правильно применять и то и другое. В ECS заложена оптимизация на современных процессорах с поддержкой кеш-линий но если не понимать как и где выделяется память, то это не даёт ничего.
>в одном бесшовном мире
Он только визуально бесшовный, а сражения 100 на 100 происходят в 20 FPS и с регистрацией попаданий в 2000 мсек когда ты умираешь и видишь уже после смерти как в тебя стреяют потому, что сервер помирает на синхронизации.
В любом случает ECS это не противоположность ООП, это просто разные подходы и вроде есть даже их гибриды, и нужно уметь правильно применять и то и другое. В ECS заложена оптимизация на современных процессорах с поддержкой кеш-линий но если не понимать как и где выделяется память, то это не даёт ничего.
>>30680
Приведу пример, как "поломка" происходит:
1. Делаем сцену, в ней десяток каких-то внутренних нод.
2. Используем эту сцену в десятке каких-либо других сцен.
3. В других сценах ставим "editable children" и что-то меняем.
4. Открываем исходную сцену, видим какую-то ошибку, фиксим.
5. После фикса запускаем игру, не подозревая никакого подвоха.
6. ВНЕЗАПНО все другие сцены потеряли настройки и поломались.
7. ???
8. Роняя ноды, бежим править проект в 10 местах одновременно.
Не лезьте в кишки через "editable children", не допускайте ошибку.
>"editable children" не рекомендуется
>он часто неожиданно ломается
Приведу пример, как "поломка" происходит:
1. Делаем сцену, в ней десяток каких-то внутренних нод.
2. Используем эту сцену в десятке каких-либо других сцен.
3. В других сценах ставим "editable children" и что-то меняем.
4. Открываем исходную сцену, видим какую-то ошибку, фиксим.
5. После фикса запускаем игру, не подозревая никакого подвоха.
6. ВНЕЗАПНО все другие сцены потеряли настройки и поломались.
7. ???
8. Роняя ноды, бежим править проект в 10 местах одновременно.
Не лезьте в кишки через "editable children", не допускайте ошибку.
Алло ООП-петухи к вам вопрос такой: если у вас десять инстансов одного класса с длинной цепочкой наследия и один инстанс такого же класса но с одним небольшим отличием, например у этого инстанса нет хп, то вы создаёте ещё одну длинную цепочку наследия с конечным классом без свойства "хп" или используете первый класс и просто лепите горбатого и хардкодите лапшу для обхода этого свойства? Просто хочу поржать с ответов, а то что-то грустно в понедельник вечером.
>>30708
Чел, шляпу про "ООП = ТОЛЬКО наследование" придумали старые заумные плюсовики на собесах, про композицию тебе уже все пояснили. (Если что, ООП это например Смоллтолк, с посылкой сообщений-сигналов объектам и без наследования, ага).
Чел, шляпу про "ООП = ТОЛЬКО наследование" придумали старые заумные плюсовики на собесах, про композицию тебе уже все пояснили. (Если что, ООП это например Смоллтолк, с посылкой сообщений-сигналов объектам и без наследования, ага).
>>30708
ООП - это ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ программирование. Где там "класс" или "наследие"?
ООП придумали как метод группировки данных и функций, работающих с этими данными, чтобы не возникало путаницы, что к чему относится. ООП можно использовать на чистых процедурных языках, не поддерживающих ООП на уровне синтаксиса. Это сложнее, чем в современных ООП языках, но всё же возможно. К тому же реализации ООП на уровне языка сильно отличаются в разных языках, т.е. в мире программирования нет одного единственного "ООП", это просто абстрактный концепт.
Классы - это шаблоны для создания объектов. Объекты могут поддерживаться языком без поддержки классов, то есть ты можешь объявить "объект" (группу данных и функций) в языке без "классов", и это одна из старых форм ООП, потому что с классами удобнее. Когда ты объявляешь "класс", ты говоришь компилятору, что хочешь иметь множество объектов, скроенных по одному шаблону - у них должны присутствовать одни и те же типы данных и функции для работы с ними. Объекты сами по себе - это уникальные сущности, и в некоторых языках созданный из класса объект можно модифицировать, чтоб получилось что-то совершенно не похожее на исходный класс.
ООП не было бы ООП, если бы ты мог обойтись единственным объектом или классом. Поэтому ООП позволяет смешивать объекты и классы в разных комбинациях разными способами. Некоторые из которых поддерживаются на уровне синтаксиса языка (как наследование), а некоторые могут быть только в голове программиста (композиция и агрегация).
Наследование - это когда ты говоришь компилятору/интерпретатору: я хочу создавать объекты, что содержат в себе типы данных и функции из нескольких классов одновременно. Т.е. вместо того, чтоб копипастить части шаблонов вручную, ты указываешь это синтаксисом языка. При этом некоторые языки позволяют только единичное наследование - когда ты вынужден создавать "цепочки наследования", тогда как другие позволяют множественное наследование (через интерфейсы или ещё как-то). Но это всё не означает, что ты обязан решать с помощью наследования все свои задачи. Это лишь инструмент, реализованный в некоторых языках с поддержкой ООП на уровне синтаксиса.
Композиция - это когда ты объявляешь, что тебе обязательно нужна ссылка на конкретный объект внутри другого объекта для работы этого объекта. Агрегация - это когда ты объявляешь, что твой объект может принять в себя объекты указанных классов, но это не обязательно для его работы и указанные объекты могут свободно входить и выходить в процессе работы. Наглядным примером агрегации в Godot является дерево сцены: ноды могут содержать в себе другие ноды, но их связи не гарантированы и могут свободно меняться в процессе исполнения программы. Примером композиции будет указание в скрипте чего-то вроде "@onready var button := $Button", поскольку твоя сцена с этой строчкой не будет правильно работать, если нода с именем Button исчезнет из дерева сцены или не будет найдена во время начального развёртывания сцены.
Очевидно, в Godot мы чаще всего работаем с агрегацией - собираем сцены из нод - и часто интуитивно используем композицию, когда указываем в своём коде get_node("Node") или $Node. Использование наследования возможно и иногда удобно, но не обязательно для того, чтобы делать ООП программу.
Таким образом, полный отказ от ООП - это не "отказ от наследования", не "отказ от классов", а отказ от концептуального комбинирования данных и функций в какие-либо группы, даже если эти группы не объявляются явным образом в коде и не поддерживаются синтаксисом языка. Если сравнить с ECS, то можно сказать, что конкретная System с запрошенными Components - это объект с точки зрения ООП, потому что мы комбинируем функции (System) с данными (Components) в одну сущность (объект). Естественно, что ECS не была бы ECS с единственной System, т.е. она состоит из многих объектов.
В каком-то смысле любая программа - это объект (в рамках операционной системы или даже всего компьютера в целом), но не любая программа - "объектно-ориентированная", поскольку для "объектно-ориентированности" должно быть несколько объектов внутри одной программы. Т.е. программа с ECS остаётся объектно-ориентированной, пока в ней есть несколько чётко ограниченных систем, каждая из которых работает с ограниченным набором компонентов (данных).
Но это всё философия по сути. Не забивайте себе этим голову...
>ООП
>класса с длинной цепочкой наследия
>ещё одну длинную цепочку наследия
ООП - это ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ программирование. Где там "класс" или "наследие"?
ООП придумали как метод группировки данных и функций, работающих с этими данными, чтобы не возникало путаницы, что к чему относится. ООП можно использовать на чистых процедурных языках, не поддерживающих ООП на уровне синтаксиса. Это сложнее, чем в современных ООП языках, но всё же возможно. К тому же реализации ООП на уровне языка сильно отличаются в разных языках, т.е. в мире программирования нет одного единственного "ООП", это просто абстрактный концепт.
Классы - это шаблоны для создания объектов. Объекты могут поддерживаться языком без поддержки классов, то есть ты можешь объявить "объект" (группу данных и функций) в языке без "классов", и это одна из старых форм ООП, потому что с классами удобнее. Когда ты объявляешь "класс", ты говоришь компилятору, что хочешь иметь множество объектов, скроенных по одному шаблону - у них должны присутствовать одни и те же типы данных и функции для работы с ними. Объекты сами по себе - это уникальные сущности, и в некоторых языках созданный из класса объект можно модифицировать, чтоб получилось что-то совершенно не похожее на исходный класс.
ООП не было бы ООП, если бы ты мог обойтись единственным объектом или классом. Поэтому ООП позволяет смешивать объекты и классы в разных комбинациях разными способами. Некоторые из которых поддерживаются на уровне синтаксиса языка (как наследование), а некоторые могут быть только в голове программиста (композиция и агрегация).
Наследование - это когда ты говоришь компилятору/интерпретатору: я хочу создавать объекты, что содержат в себе типы данных и функции из нескольких классов одновременно. Т.е. вместо того, чтоб копипастить части шаблонов вручную, ты указываешь это синтаксисом языка. При этом некоторые языки позволяют только единичное наследование - когда ты вынужден создавать "цепочки наследования", тогда как другие позволяют множественное наследование (через интерфейсы или ещё как-то). Но это всё не означает, что ты обязан решать с помощью наследования все свои задачи. Это лишь инструмент, реализованный в некоторых языках с поддержкой ООП на уровне синтаксиса.
Композиция - это когда ты объявляешь, что тебе обязательно нужна ссылка на конкретный объект внутри другого объекта для работы этого объекта. Агрегация - это когда ты объявляешь, что твой объект может принять в себя объекты указанных классов, но это не обязательно для его работы и указанные объекты могут свободно входить и выходить в процессе работы. Наглядным примером агрегации в Godot является дерево сцены: ноды могут содержать в себе другие ноды, но их связи не гарантированы и могут свободно меняться в процессе исполнения программы. Примером композиции будет указание в скрипте чего-то вроде "@onready var button := $Button", поскольку твоя сцена с этой строчкой не будет правильно работать, если нода с именем Button исчезнет из дерева сцены или не будет найдена во время начального развёртывания сцены.
Очевидно, в Godot мы чаще всего работаем с агрегацией - собираем сцены из нод - и часто интуитивно используем композицию, когда указываем в своём коде get_node("Node") или $Node. Использование наследования возможно и иногда удобно, но не обязательно для того, чтобы делать ООП программу.
Таким образом, полный отказ от ООП - это не "отказ от наследования", не "отказ от классов", а отказ от концептуального комбинирования данных и функций в какие-либо группы, даже если эти группы не объявляются явным образом в коде и не поддерживаются синтаксисом языка. Если сравнить с ECS, то можно сказать, что конкретная System с запрошенными Components - это объект с точки зрения ООП, потому что мы комбинируем функции (System) с данными (Components) в одну сущность (объект). Естественно, что ECS не была бы ECS с единственной System, т.е. она состоит из многих объектов.
В каком-то смысле любая программа - это объект (в рамках операционной системы или даже всего компьютера в целом), но не любая программа - "объектно-ориентированная", поскольку для "объектно-ориентированности" должно быть несколько объектов внутри одной программы. Т.е. программа с ECS остаётся объектно-ориентированной, пока в ней есть несколько чётко ограниченных систем, каждая из которых работает с ограниченным набором компонентов (данных).
Но это всё философия по сути. Не забивайте себе этим голову...
>>30708
ООП - это ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ программирование. Где там "класс" или "наследие"?
ООП придумали как метод группировки данных и функций, работающих с этими данными, чтобы не возникало путаницы, что к чему относится. ООП можно использовать на чистых процедурных языках, не поддерживающих ООП на уровне синтаксиса. Это сложнее, чем в современных ООП языках, но всё же возможно. К тому же реализации ООП на уровне языка сильно отличаются в разных языках, т.е. в мире программирования нет одного единственного "ООП", это просто абстрактный концепт.
Классы - это шаблоны для создания объектов. Объекты могут поддерживаться языком без поддержки классов, то есть ты можешь объявить "объект" (группу данных и функций) в языке без "классов", и это одна из старых форм ООП, потому что с классами удобнее. Когда ты объявляешь "класс", ты говоришь компилятору, что хочешь иметь множество объектов, скроенных по одному шаблону - у них должны присутствовать одни и те же типы данных и функции для работы с ними. Объекты сами по себе - это уникальные сущности, и в некоторых языках созданный из класса объект можно модифицировать, чтоб получилось что-то совершенно не похожее на исходный класс.
ООП не было бы ООП, если бы ты мог обойтись единственным объектом или классом. Поэтому ООП позволяет смешивать объекты и классы в разных комбинациях разными способами. Некоторые из которых поддерживаются на уровне синтаксиса языка (как наследование), а некоторые могут быть только в голове программиста (композиция и агрегация).
Наследование - это когда ты говоришь компилятору/интерпретатору: я хочу создавать объекты, что содержат в себе типы данных и функции из нескольких классов одновременно. Т.е. вместо того, чтоб копипастить части шаблонов вручную, ты указываешь это синтаксисом языка. При этом некоторые языки позволяют только единичное наследование - когда ты вынужден создавать "цепочки наследования", тогда как другие позволяют множественное наследование (через интерфейсы или ещё как-то). Но это всё не означает, что ты обязан решать с помощью наследования все свои задачи. Это лишь инструмент, реализованный в некоторых языках с поддержкой ООП на уровне синтаксиса.
Композиция - это когда ты объявляешь, что тебе обязательно нужна ссылка на конкретный объект внутри другого объекта для работы этого объекта. Агрегация - это когда ты объявляешь, что твой объект может принять в себя объекты указанных классов, но это не обязательно для его работы и указанные объекты могут свободно входить и выходить в процессе работы. Наглядным примером агрегации в Godot является дерево сцены: ноды могут содержать в себе другие ноды, но их связи не гарантированы и могут свободно меняться в процессе исполнения программы. Примером композиции будет указание в скрипте чего-то вроде "@onready var button := $Button", поскольку твоя сцена с этой строчкой не будет правильно работать, если нода с именем Button исчезнет из дерева сцены или не будет найдена во время начального развёртывания сцены.
Очевидно, в Godot мы чаще всего работаем с агрегацией - собираем сцены из нод - и часто интуитивно используем композицию, когда указываем в своём коде get_node("Node") или $Node. Использование наследования возможно и иногда удобно, но не обязательно для того, чтобы делать ООП программу.
Таким образом, полный отказ от ООП - это не "отказ от наследования", не "отказ от классов", а отказ от концептуального комбинирования данных и функций в какие-либо группы, даже если эти группы не объявляются явным образом в коде и не поддерживаются синтаксисом языка. Если сравнить с ECS, то можно сказать, что конкретная System с запрошенными Components - это объект с точки зрения ООП, потому что мы комбинируем функции (System) с данными (Components) в одну сущность (объект). Естественно, что ECS не была бы ECS с единственной System, т.е. она состоит из многих объектов.
В каком-то смысле любая программа - это объект (в рамках операционной системы или даже всего компьютера в целом), но не любая программа - "объектно-ориентированная", поскольку для "объектно-ориентированности" должно быть несколько объектов внутри одной программы. Т.е. программа с ECS остаётся объектно-ориентированной, пока в ней есть несколько чётко ограниченных систем, каждая из которых работает с ограниченным набором компонентов (данных).
Но это всё философия по сути. Не забивайте себе этим голову...
>ООП
>класса с длинной цепочкой наследия
>ещё одну длинную цепочку наследия
ООП - это ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ программирование. Где там "класс" или "наследие"?
ООП придумали как метод группировки данных и функций, работающих с этими данными, чтобы не возникало путаницы, что к чему относится. ООП можно использовать на чистых процедурных языках, не поддерживающих ООП на уровне синтаксиса. Это сложнее, чем в современных ООП языках, но всё же возможно. К тому же реализации ООП на уровне языка сильно отличаются в разных языках, т.е. в мире программирования нет одного единственного "ООП", это просто абстрактный концепт.
Классы - это шаблоны для создания объектов. Объекты могут поддерживаться языком без поддержки классов, то есть ты можешь объявить "объект" (группу данных и функций) в языке без "классов", и это одна из старых форм ООП, потому что с классами удобнее. Когда ты объявляешь "класс", ты говоришь компилятору, что хочешь иметь множество объектов, скроенных по одному шаблону - у них должны присутствовать одни и те же типы данных и функции для работы с ними. Объекты сами по себе - это уникальные сущности, и в некоторых языках созданный из класса объект можно модифицировать, чтоб получилось что-то совершенно не похожее на исходный класс.
ООП не было бы ООП, если бы ты мог обойтись единственным объектом или классом. Поэтому ООП позволяет смешивать объекты и классы в разных комбинациях разными способами. Некоторые из которых поддерживаются на уровне синтаксиса языка (как наследование), а некоторые могут быть только в голове программиста (композиция и агрегация).
Наследование - это когда ты говоришь компилятору/интерпретатору: я хочу создавать объекты, что содержат в себе типы данных и функции из нескольких классов одновременно. Т.е. вместо того, чтоб копипастить части шаблонов вручную, ты указываешь это синтаксисом языка. При этом некоторые языки позволяют только единичное наследование - когда ты вынужден создавать "цепочки наследования", тогда как другие позволяют множественное наследование (через интерфейсы или ещё как-то). Но это всё не означает, что ты обязан решать с помощью наследования все свои задачи. Это лишь инструмент, реализованный в некоторых языках с поддержкой ООП на уровне синтаксиса.
Композиция - это когда ты объявляешь, что тебе обязательно нужна ссылка на конкретный объект внутри другого объекта для работы этого объекта. Агрегация - это когда ты объявляешь, что твой объект может принять в себя объекты указанных классов, но это не обязательно для его работы и указанные объекты могут свободно входить и выходить в процессе работы. Наглядным примером агрегации в Godot является дерево сцены: ноды могут содержать в себе другие ноды, но их связи не гарантированы и могут свободно меняться в процессе исполнения программы. Примером композиции будет указание в скрипте чего-то вроде "@onready var button := $Button", поскольку твоя сцена с этой строчкой не будет правильно работать, если нода с именем Button исчезнет из дерева сцены или не будет найдена во время начального развёртывания сцены.
Очевидно, в Godot мы чаще всего работаем с агрегацией - собираем сцены из нод - и часто интуитивно используем композицию, когда указываем в своём коде get_node("Node") или $Node. Использование наследования возможно и иногда удобно, но не обязательно для того, чтобы делать ООП программу.
Таким образом, полный отказ от ООП - это не "отказ от наследования", не "отказ от классов", а отказ от концептуального комбинирования данных и функций в какие-либо группы, даже если эти группы не объявляются явным образом в коде и не поддерживаются синтаксисом языка. Если сравнить с ECS, то можно сказать, что конкретная System с запрошенными Components - это объект с точки зрения ООП, потому что мы комбинируем функции (System) с данными (Components) в одну сущность (объект). Естественно, что ECS не была бы ECS с единственной System, т.е. она состоит из многих объектов.
В каком-то смысле любая программа - это объект (в рамках операционной системы или даже всего компьютера в целом), но не любая программа - "объектно-ориентированная", поскольку для "объектно-ориентированности" должно быть несколько объектов внутри одной программы. Т.е. программа с ECS остаётся объектно-ориентированной, пока в ней есть несколько чётко ограниченных систем, каждая из которых работает с ограниченным набором компонентов (данных).
Но это всё философия по сути. Не забивайте себе этим голову...
>>30708
А ты вот не лепишь. В ecs, не в ecs - если наступает ситуация когда вдруг, снихуя, в продуманную иерархию внедряется одно дополнительное важное условие, ломающее всё - ты будешь лепить горбатого либо править то что есть. Возьмем ecs - у тебя десятки мобов с которыми работает один набор систем, а тут хуяк появляется моб - всё поведение которого зависит от наличия определенного компонента на нем, про который другие системы не знают, и им нужно помимо самого моба еще и менять сам этот компонент. И ты встаешь перед выбором - править то что есть или начинать лепить горбатого, реализовывая логику прям в компоненте либо встраивая несколько промежуточных систем обеспечивающих работу твоего проблемного случая. Так что ваши горба не меньше наших, особенно учитывая специфику ecs и его любовь к раздуванию кодовой базы и наборов компонентов флагами.
>Лепим горбатого
А ты вот не лепишь. В ecs, не в ecs - если наступает ситуация когда вдруг, снихуя, в продуманную иерархию внедряется одно дополнительное важное условие, ломающее всё - ты будешь лепить горбатого либо править то что есть. Возьмем ecs - у тебя десятки мобов с которыми работает один набор систем, а тут хуяк появляется моб - всё поведение которого зависит от наличия определенного компонента на нем, про который другие системы не знают, и им нужно помимо самого моба еще и менять сам этот компонент. И ты встаешь перед выбором - править то что есть или начинать лепить горбатого, реализовывая логику прям в компоненте либо встраивая несколько промежуточных систем обеспечивающих работу твоего проблемного случая. Так что ваши горба не меньше наших, особенно учитывая специфику ecs и его любовь к раздуванию кодовой базы и наборов компонентов флагами.
>>30741
Ты точно понимаешь суть ECS? Системы вызываются только при наличии компонента, там у стоит query на наличие нужного компонента. Остальные энтити про них даже знать не должны.
Ты точно понимаешь суть ECS? Системы вызываются только при наличии компонента, там у стоит query на наличие нужного компонента. Остальные энтити про них даже знать не должны.
>>30746
Так бывает только в бенчмарках со 100к одинаковых спрайтов, в реальной жизни так не бывает, поэтому ецс не пригоден для разработки.
Так бывает только в бенчмарках со 100к одинаковых спрайтов, в реальной жизни так не бывает, поэтому ецс не пригоден для разработки.
>>30746
Без вертикальных конструкций эта хуйня не работает. А если ты мне скажешь что ты не используешь компоненты-флажки для того чтобы активировать дополнительные системы в зависимости от текущего состояния сущности - это значит что ты про ecs только в хабре прочитал. А чтобы встроить в эту цепочку проброса флажков которая в итоге и строит игровой процесс сущности вот такой хитрый компонент, который как бы должен нарушать работу других систем, связанных с этой сущностью, так как им нужно будет опираться на состояние компонента, который им неизвестен - тебе либо придется редактировать системы, либо писать дополнительные системы корректирующие существующие системы, либо лепить горбатого прямо в существующих компонентах + небольшое редактирование систем. Суммарно - делать то же что и в ооп, просто учитывая специфику ecs.
Без вертикальных конструкций эта хуйня не работает. А если ты мне скажешь что ты не используешь компоненты-флажки для того чтобы активировать дополнительные системы в зависимости от текущего состояния сущности - это значит что ты про ecs только в хабре прочитал. А чтобы встроить в эту цепочку проброса флажков которая в итоге и строит игровой процесс сущности вот такой хитрый компонент, который как бы должен нарушать работу других систем, связанных с этой сущностью, так как им нужно будет опираться на состояние компонента, который им неизвестен - тебе либо придется редактировать системы, либо писать дополнительные системы корректирующие существующие системы, либо лепить горбатого прямо в существующих компонентах + небольшое редактирование систем. Суммарно - делать то же что и в ооп, просто учитывая специфику ecs.
>>30756
Годачую. Я их давно не читаю, будто тот шиз с антипаттернами размножился почкованием и сам с собой философствует. Кому-то ООП мешает, кому-то композиция, кто-то в голове у себя третью игру релизит, охуеть. Мусорный контент просто, зашел, пролистал не читая, дальше работать пошел.
Годачую. Я их давно не читаю, будто тот шиз с антипаттернами размножился почкованием и сам с собой философствует. Кому-то ООП мешает, кому-то композиция, кто-то в голове у себя третью игру релизит, охуеть. Мусорный контент просто, зашел, пролистал не читая, дальше работать пошел.
>>30759
В субшота-треде нейтральная территория - для всех и каждого.
Godot-тред - для творчества на Godot или связанного с Godot.
В субшота-треде нейтральная территория - для всех и каждого.
Godot-тред - для творчества на Godot или связанного с Godot.
>>30680
Чудовищный бойлерплейт вместо игрыхелловорда, эффективного кода на глаз пару процентов. Похожее видел много раз, когда без кодогенераторов уже не обойтись. Хуевый пример как минимум. А скорее всего хуевое попросто все.
Чудовищный бойлерплейт вместо игрыхелловорда, эффективного кода на глаз пару процентов. Похожее видел много раз, когда без кодогенераторов уже не обойтись. Хуевый пример как минимум. А скорее всего хуевое попросто все.
>>30778
Есть такое свойство у архитектуры. Она нужна для больших проектов. (Тот прикол про слои абстракции и новую проблему, решаемую новым слоем абстракции). Если ты планируешь всю жизнь делать только мелкоигры на джемы - она не нужна, можешь хоть синглтонами писать. Если же хочешь расти на будущее, то лучше ее применять даже в мелких проектах.
Есть такое свойство у архитектуры. Она нужна для больших проектов. (Тот прикол про слои абстракции и новую проблему, решаемую новым слоем абстракции). Если ты планируешь всю жизнь делать только мелкоигры на джемы - она не нужна, можешь хоть синглтонами писать. Если же хочешь расти на будущее, то лучше ее применять даже в мелких проектах.
>>30788
Странно, а у меня десяток релизнутых игр на годоте, что-то с твоими словами не бьется.
Странно, а у меня десяток релизнутых игр на годоте, что-то с твоими словами не бьется.
>>30789
Так ведь и я на линуксе через протон/вайн могу играть. С багами, неполной совместимостью, вылетами, красноглазингом самого вайно и его настроек, но всё же могу. Так и с годотом.
Так ведь и я на линуксе через протон/вайн могу играть. С багами, неполной совместимостью, вылетами, красноглазингом самого вайно и его настроек, но всё же могу. Так и с годотом.
>>30792
Хуевому танцору, как говорится.
Хуевому танцору, как говорится.
>>30701
Вот именно. Оптимизация заключается в том, что игра должна процессору предоставить списки с однородными данными атомарного типа, записанными на стеке и формулу преобразования этих данных в новый массив с новыми данными, который процессор отдаст игре. А как эти списки применяются игрой - не принципиально. ЕЦС говорит о том, что у неё нет классических классов, поэтому у них не ООП (о том что ООП не обязательно классы, они видимо забыли или не знали), у них сущности, данные которых оптимизированы в однородные списки, каждым списком заведует система, сущности объединены в иерархию, являясь друг другу компонентами.
Проблема в том, что ничто не мешает, зная принципы работы кэша процессора, завести те же самые списки внутри удобной ООП-игры, и так же их скармливать процу, чтобы быстро вычислять большие объёмы однородных данных. Физические движки примерно так и работают. У тебя куча разных объектов, но имеющих нужный интерфейс, движок собирает у них всех трансформы и вектора в однородный список, производит расчёт следующего состояния физической симуляции, и раздаёт объектам обновлённые данные.
> В ECS заложена оптимизация на современных процессорах с поддержкой кеш-линий но если не понимать как и где выделяется память, то это не даёт ничего.
Вот именно. Оптимизация заключается в том, что игра должна процессору предоставить списки с однородными данными атомарного типа, записанными на стеке и формулу преобразования этих данных в новый массив с новыми данными, который процессор отдаст игре. А как эти списки применяются игрой - не принципиально. ЕЦС говорит о том, что у неё нет классических классов, поэтому у них не ООП (о том что ООП не обязательно классы, они видимо забыли или не знали), у них сущности, данные которых оптимизированы в однородные списки, каждым списком заведует система, сущности объединены в иерархию, являясь друг другу компонентами.
Проблема в том, что ничто не мешает, зная принципы работы кэша процессора, завести те же самые списки внутри удобной ООП-игры, и так же их скармливать процу, чтобы быстро вычислять большие объёмы однородных данных. Физические движки примерно так и работают. У тебя куча разных объектов, но имеющих нужный интерфейс, движок собирает у них всех трансформы и вектора в однородный список, производит расчёт следующего состояния физической симуляции, и раздаёт объектам обновлённые данные.
>>31204
А ты кто будешь? И что ты тут делаешь?
А ты кто будешь? И что ты тут делаешь?
304 Кб, 1901x1077Ребят, пилю рпг-рогалик на годоте, пока ещё в активной разработке, но уже в целом визуальный стиль я думаю видно. Рейтаните. Игрой занимаюсь активно уже более 3-х месяцев. Если что, первый мой проект, соответственно, каждый шаг даётся с большим трудом, но по крайней мере "медленно - но верно" :)