Шапка: https://hipolink.me/godothread
Предыдущий: >>963889 (OP)
Архивный: >>958498 (OP)
да я ебал
я такой страшной хуйни на шизокодил что сам испугался и ушел прокрастинировать
тоесть рисовать
Почему без зрачков лого выглядит в разы лучше?
> в чём проблема? Кто может подсказать?
Контроллер не учитывает реальный угол модельки, работает с тем, что преднастроено и поворачивает, добавляя углы.
Если не хочешь заморачиваться с матчастью и просто продолжить делать игру дальше, то допиши в _ready() своего контроллера
> Player.transform = Player.transform.orthonormalized()
Это должно сбросить твои повороты и масштабирования, которые ты накрутил в редакторе.
Если хочешь следовать за белым кроликом и узнать, насколько глубока кроличья нора, то вот тебе точка входа:
https://godot-ru.readthedocs.io/ru/4.x/tutorials/3d/using_transforms.html
> Предполагаю, что контроллер не учитывает реальный угол модельки, работает с тем, что преднастроено и поворачивает, добавляя углы.
быстрофикс
Видос не смотрел. У себя сделал так:
= Spatial
== Pivot
=== кинематик, меш и все остальное
Верхний Spatial никогда не поворачиваю. За все повороты отвечает пивот. Чтобы поворачивать из редактора добавил пару строк в _ready, которые при наличии у Spatial поворота сбрасывают его в ноль и устанавливают такой же поворот на пивот. Как делать правильней не знаю, у меня пока все работает.
Звучит интересно. А я в итоге полистал комменты под видео, и там у кого-то такая же проблема была и он решение написал.
Удалять и перемещать файлы - только через редактор.
К вопросу о том, нахуя нужно окно файловой системы на всю ширину.
Ну у меня или баг, или защита от дурака. Кароче есть сцена, main. Есть scene_holder. Он по дефолту содержит scene_1. В этой сцене есть area3d, которая должна перемещать на другую сцену. Для этого у нее есть переменная @export var another_scene: PackedScene. Я в редакторе в эту переменную закладываю scene_2. У неё такой же переход есть, area3d, с такой же переменной, только в ней заложен scene_1. Ну так я думал должны работать переходы между сценами. В итоге работает в одну сторону. Во вторую внезапно нет. Потому-что переменная another_scene в scene_2 теряет тот PackedScene, что я закладывал в неё в редакторе. И потом после ReloadCurrentProject у меня все зависимости рушатся. Нагуглил, вроде какая то цикличная хуйня начинается, но какого хуйя в редакторе то? И почему у меня со второй сцены PackedScene съёбывается. Чудеса ебаные.
Ну так просто создай новый проект и туда закинь все. Или удали папку с кешем в проекте и все связи пересоздадуться
Скорее всего, при PackedScene в переменной хранится ВСЯ ДРУГАЯ СЦЕНА и да, получается циклическая зависимость.
Храни путь к сцене или строку с именем.
У них донат через пейпалку, а палка дохуя геморная для РФ даже когда она с нами работала. Теперь вообще гроб кладбище. А то бы и сейчас баксов по 25 закидывал.
По хардкору кто шарит поясните по паре пунктов
Если сравнивать с юнити на сколько проще/сложнее в соло делать небольшую 3Д игрушку??
Перекатываться с той же юнити сильно больно и не приятно??
Основные положительные и отрицательные сравнения с юнити?
По собственному естественно опыту, тем кто пользовался и тем и тем.
Ну бля скачай, да пройди туториал хотя бы, делов на вечер-два.
>Ну бля скачай, да пройди туториал хотя бы, делов на вечер-два.
Лол, ты троллишь или реально хлебушек?
Опыт годами получается а не за вечер-два, везде есть миллион подводных и тонкости.
Вообще зачем ответил если такой бред отписал. Там же специально строчка последняя об опыте.
>Опыт годами получается а не за вечер-два, везде есть миллион подводных и тонкости.
>скажите
Сам нахуй пойдёшь или тебя послать?
Юнька - ебешься с капризной но богатой жирухой, хуй ее поднимешь, вечно ей что-то не так. Воняет.
Годот - ебешься с согласной на все нефоршей-студенткой.
Ебать комьюнити нахуй.
Тебе все по делу сказали. Скачай до посмотри, займет вечер. Мы тут хуй знаем какой у тебя опыт, предпочтения, скиллы, на каком языке ты предпочтешь писать, какие у тебя, бля, потребности. Раз мы тут - очевидно что нам годот оказался пизже. А тебе, возможно, не окажется, и ты с горящей жопой прибежишь вонять что сообщество сектантов тебя наебало И НА САМОМ ДЕЛЕ ВСЕ НЕ ТАК.
От себя скажу что да, 3д делаю вот прямщас легко. Перекат дался без задней мысли. Основной плюс - годот не ебет мозги, съебывается в сторону и не мешает тебе работать. Теперь иди туториал проходи.
Короче хочешь хлебнуть питонячего граница лопаткой тебе годот пойдет со всеми вытекающими и вытекающими "я хуй знает что этот за тип я просто упаду"
Если хочешь сишного говна но по сайту и чтобы тебе его переделывали и в в рот запихивал то на юнити с c# будешь кушать нульрефы зато мягенько.
Ну ещё на юнити говна переработанного побольше будет в виде халявные биомусорных асетов.
Остальная разница особого смысла не несёт.
Репортим.
>богатой
Не смотря на это, периодически требует проценты с тебя.
Почему? Я верю в тебя анон. И в себя верю
>>970792
Обещали сделать свой донатный сервис
>>970790
Лол, проблема в том, что его невозможно купить. Лицензия MIT буквально позволяет взять исходники и продавать их на рынке за 25 баксов. То есть непонятно, что ты покупаешь если оно и так уже доступно для коммерциализации. Только разработчиков движка, но их там меньше 10 человек на постоянной зарплате
> на сколько проще/сложнее в соло делать небольшую 3Д игрушку??
Индивидуально. Мне - проще на годоте.
>Перекатываться сильно больно и не приятно??
Индивидуально. В годоте удобный интерфейс, но естественно он другой, поэтому надо сразу выкинуть идею "должно быть как в продуктнейм".
>Основные положительные и отрицательные сравнения с юнити?
А не пошел бы ты в движкосрач с таким байтом?
>>970776
>переходы между сценами
>>970780
>Храни путь к сцене или строку с именем
И путь, и имя могут измениться. Потом искать все строки, где это было использовано и менять...
Ладно, спасибо. Этот вариант работает, в отличии от всего, что я пытался сделать с PackedScene. Жаль, конечно. С ними удобнее было.
Как это работает? Разве я например не могу смотря эти стримы своровать исходный код игры и сделать клон буквально в момент выхода оригинала?
Ну если ты гений маркетинга и думаешь что можешь обеспечить прекрасные продажи неоригинальному калу, то ты мог своровать уже много игр из учебников и мануалов с ютуба и собрать по кускам. А, или это уже был бы твой труд? Так или иначе многие учатся программировать и кодят на стримах, бери и повторяй.
https://www.youtube.com/watch?v=nAh_Kx5Zh5Q
Пчел, ты так ничего и не понял. Если ты сейчас пойдешь и выложишь реализацию своей уникальной идеи на гитхаб - всем похуй будет. Еще воровать чего-то у кого-то. Тут бы заставить людей поиграть в свое говно. Хоть на улице отлавливай и в монитор тыкай как котят.
Блин, а если я выпустил трейлер, который собрал 200 000 просмотров? Неужели и правда всем Окей, что код становиться публичным?
>если
Если - возможно. Но ты не. И хрен с ютуба не.
Я всего один раз видел чтобы игру реально украли и успешно продавали после минимального рескина. Оригинальный автор выкатил публичную жалобу в своем Х, предоставил публичные пруфы, вора заспамили абьюз-репортами и отовсюду удалил. Конец.
>Как это работает? Разве я например не могу смотря эти стримы своровать исходный код игры и сделать клон буквально в момент выхода оригинала?
Там за 2 часа стрима кубик перемещается по полю, тырить ты это будешь еще дольше, а главный вопрос начерта?
Учитывая что почти любая игра это на коленка сделанный кусок сферического кала закреаленный козявками чтобы не развалилось.
>почти любая игра это на коленка сделанный кусок сферического кала
Но только не твоя, да?
Как лучше реализовывать игровой интерфейс:
- В качестве дочерней ноды игрока?
- В качестве дочерней ноды к уровню?
- Ставить его на автозагрузку?
Также, у кого есть ссылка на гайд по грамотной организации проекта (и файловой системы, и иерархии нод), милости прошу
>- Ставить его на автозагрузку?
Я всегда так делаю. Небольшую часть гуя можно вставить в игрока, если это намертво привязано к игроку - типа хп бара над его головой
https://www.youtube.com/@sora_sakurai_en
Нет никакой грамотной организации. Есть только удобные лично тебе.
Спасибо, добавил в подписки. В свою очередь могу посоветовать Adam Milliard тоже про геймдизайн на примере реальных игр
https://youtube.com/@architectofgames?si=NWp-rTZAV3heJYqU
У меня в целом плоская организация
GameScene
-WorldScene
--Env (Sun, WorldEnv, OceanShader...)
--Level (Terrain, Objects)
-Player
-CameraRig
-GuiCanvasLayer
-HUD/GUI
--PlayerHUD
res://
│
├── assets/ # Внешние ресурсы
│ ├── sprites/ # Спрайты и изображения
│ │ ├── characters/ # Спрайты персонажей
│ │ ├── environment/ # Спрайты окружения
│ │ └── items/ # Спрайты предметов
│ ├── animations/ # Анимации (например, .anim файлов)
│ ├── sounds/ # Звуковые эффекты и музыка
│ ├── fonts/ # Шрифты
│ └── tilesets/ # Тайлы и тайлсеты для уровней
│
├── scenes/ # Игровые сцены
│ ├── main/ # Главные сцены (например, основное меню, игра)
│ ├── characters/ # Сцены персонажей (Player, NPC)
│ ├── environment/ # Сцены окружения (уровни, фоны)
│ ├── ui/ # Сцены интерфейса
│ └── items/ # Сцены предметов (если предметы имеют свою логику)
│
├── scripts/ # Скрипты
│ ├── global/ # Глобальные скрипты (менеджеры, утилиты и т.д.)
│ ├── characters/ # Скрипты персонажей
│ ├── environment/ # Скрипты окружения
│ ├── ui/ # Скрипты интерфейса
│ └── items/ # Скрипты предметов
│
├── resources/ # Ресурсы Godot (например, .tres и .res файлы)
│ ├── materials/ # Материалы (если используются)
│ ├── shaders/ # Шейдеры (если используются)
│ └── prefabs/ # Префабы (готовые компоненты для переиспользования)
│
├── ui/ # Интерфейсы (помимо сцен)
│ ├── themes/ # Темы интерфейса
│ └── widgets/ # Отдельные виджеты и элементы UI
│
├── addons/ # Плагины Godot и сторонние аддоны
│
└── project.godot # Файл конфигурации проекта
Могу предположить что бы было как реф
>>971040
Фуххх..... только с работы приполз, да не вопрос лови!!!
Зачем такое в реф? В годоте не принято разносить скрипт и сцену по разным веткам.
естественно
https://docs.godotengine.org/en/stable/tutorials/best_practices/project_organization.html
вот только там про скрипты ни слова, но в целом и не беда.
>>971044
ну как бэ да и не да в одном флаконе, в целом вопрос был про грамотную организацию и я когда этот вопрос изучал +- наткнулся на такой варик, выписал себе его отдельно, поправил и по нему шуршу - удобно.
Дело не в гайде, а в том, что когда ты создаешь сцену и скрипт в ней, по умолчанию он создается рядом - менять это очень много времени занимает.
Так вот вопрос: почему некоторые знают, какую ноду когда использовать, а какую нет? Ну т.е. в документации такие вещи не пишут и это сакральное знание передаётся от двачера к двачеру или кто-то не читает доку достаточно внимательно? Часто есть проекты(не в геймдеве), где вообще не написано, как пользоваться частью функционала, а просто пишет какие-то спеки для программистов и подразумевается, что ты уже что-то знаешь из предыдущего опыта. Но задачи, с которыми встречаются в этих вопросах вполне себе типовые и неужели такие популярные вещи не описаны? Или описаны плохо? Поясните, кто шарит.
Для клиента действует правило: как понятней всем разработчикам клиента. То есть есть некая конвенция, с которой все согласны и пишут по ней.
Для библиотек ситуация другая, там нужно поддерживать обратную совместимость и многие решения просто невозможно расширить в будущем без ломания совместимости. Поэтому просто согласиться делать так-то не получиться, нужно ещё учитывать обратную совместимость.
Клиент для игры относиться к первому варианту, так что по правилу большого пальца используй те решения, которые общепринятые и когда придет новый разработчик на проект он будет сразу понимать что где лежит.
Да, это вполне оправданная политика и такой подход так же имеет право на жизнь и более того он изначально так и задумывался, а дальше кому как удобнее, у меня к примеру на одну сцену не по одному скрипту и даже не по 2 - юзаю компоненты и классы и синглтоны.
>>971069
Тут могу только из своего опыта ответить или правильнее на своем опыте =) +- и то и друое и 3е!
У годо в целом очень и очень неплохая документация, но
1) есть некоторые случаи когда одна или иная реализация конкретного функционала цепляется в конечном итоге за конкретные ограничения другого функционала (привет попытка угадить всем и вся - аля обратка) и в твоем конкретном случае если ты в дальнейшем будешь планировать расширять его лучше сразу заюзать другие штуки) пример - плеер анимации и анимированный спрайт в зависимости от сценария использования исходников и пр сиди выбирай.
2) документация ништяк да, но есть пробелы и недоразумения - ага
пример - есть источник света у него есть параметр add mix sub и из названий и описания вроде все должно быть ясненько и я потратил целый вечер пытаясь понять почему add на черном не светиться - как итог я вычитал и на форуме и на гите, что !!! ребята из годо основываются на физике процесса (ну тип если посветить в абсолютно черный он же останется черным), а не на математике и если глянуть под капот в движок, то можно увидеть там multiply и ясен пень "ты" при умножении на 0 получаешь ноль ну круто!!! только не мне и еще некоторому кол-ву разрубов это прям колом встало, переименуйте параметр паразиты и сделайте реализацию как у всех
3) исторически сложилось + опыт + особенности
Опыт. Это приходит с опытом. Не будь из тех кто задрачивает бесконечные туториалы и внемлет гуру, а сам не делает нихуя.
Рассматривай все как некий конвеер из узлов которые что-то получают на входе и выдают результат. Поэтому одну и ту же задачу можно решить разными способами, как можно в детском конструкторе собрать подъемник разными способами. А дальше все упирается в (обычно программистский) опыт, какие элементы будут жрать слишком много, какие просто неудачно между собой сочетаются.
Обычно нет миллиона способов. Есть миллион комбинаций вообще в принципе, но нужных тебе делающих твою задачу штук 6. Их можно банально перепробовать.
Ну 6 для меня звучит вполне себе как миллион, учитывая, что это лишь один из узлов, а если в цепочке 2 узла, то комбинации этого увеличиваются значительно, а если 3?
>>971088
1. Заведётся ли на Линуксе код на Шарпе?
2. Легко ли писать голые GLSL шейдеры(совместимы ли)?
3. Голые OBJ-модели без конвертации поддерживает?
Речь о последней версии.
Если нюфаг гдскрипт возьми. Попроще, полегче, интеграция глубже, документации больше.
Я говорил уже про комбинации. И обычно актуальных способов меньше, может 3.
Ну например в твоем примере надо смотреть только на то, чем можно крутить.
В годоте свой шейдерный язык, котлрый компилируется в шейдеры разных платформ.
Си шарп и годот мне кажется сомнительная комбинация. Первостепенный язык гдскрипт, все обучающие видеоролики используют гдскрипт. Выбирая си шарп ты увеличишь себе сложность, возможно зря.
Расслабься.
Я ебланил на всех уроках кроме алгебры и геометрии. Мат-дисциплины я любил и сдавал их на 4 и 5, плюс решал домашку/контрольные другим учениками за деньги. Могу тебе уверенно сказать что школьная программа вот во всем этом геймдеве не помогает почти никак. То что нам преподают на уроках просто максимально оторвано от практических задач и тебе приходится потом переучиваться самостоятельно.
Не в моём случае, либо я задачу ставил уебански, но что забавно так это то что финальное решение пришло во время того как я пытался выдолбить его у чатжпт, а он мне продолжал выдавать хуйню, и видимо от баттхёрта ко мне пришла идея.
>>971119
Самый большой доёб к школе и универу у меня скорее к тому что у меня убили моё естественное желание обучаться настолько, что после выпуска я какое-то время думал что мне просто не нравится учить что-то новое. Оказалось что пиздец как нравится, но мне пришлось потратить несколько лет на восстановление природного любопытства.
Сегодня устал на РАБоте. Буду смотреть фильмы, коллекционировать хорошие моменты
Сегодня доделол боевку в годоте наконец. Это я выше со школьной математикой ебался. Теперь нужен вражина чтобы его отпиздить
> Теперь нужен вражина чтобы его отпиздить
Сделай арбузы и груши, летящие сверху вниз. И чтобы их рубить.
А вообще неплохая идея, это отличный способ протестить боевку без создания ИИ и моделек для врагов. Пожалуй так и сделаю. Спасибо.
Обосрался.
>>971171
Интересно что и гейммейкер вырос, и анрил, и годот. Только юнька упала и в абсолютных значениях и в процентных.
Судя по тому что кружок немного сдвинут, это хуйню кто-то ручками делает каждый год, вместо того чтобы нахуярить утилиту для автоматизации. Пиздец просто.
> Интересно что и гейммейкер вырос, и анрил, и годот. Только юнька упала и в абсолютных значениях и в процентных.
Ну так известно почему - install fee. Про неё оказывается уже игру сделоли, лол
https://3dnews.ru/1094306/po-motivam-skandala-s-novoy-biznes-modelyu-unity-v-steam-vyshla-satiricheskaya-igra-install-fee-tycoon
Ога, хуярить утилиту для автоматизации чего-то, что ты делаешь раз в год.
существует ли в годо возможность реализовать локальный мультиплеер? т.е. писать айпи хоста и по айпишнику заходить на сервер и игрунькать?
существует ли в годо возможность реализовать локальный мультиплеер? т.е. писать айпи хоста и по айпишнику заходить на сервер и игрунькать?
А ну да, я забыл что не все такие аутисты как я у которых тряска от того что если я заранее знаю что буду что-то делать больше 1 раза и могу автоматизировать, то теряю сон пока не автоматизирую.
Так это статистика по геймджемам, на нее смотреть это такая себе история. То что там анрил вообще есть это в принципе фантастика.
>То что там анрил вообще есть это в принципе фантастика.
Почему? Если там нет условия типа "только веб" или "только 2Д" то анрил очень даже норм выбор.
По самому крупному геймджему. Но ты прав, это не показатель - это звоночек, учитывая что предыдущие лет 5 юнити там была 60%+
>статистика по геймджемам
И? Ты сам себе выдумал что это статистика по стиму или что?
>Почему?
Ну типо геймджем это собрать по быстрому какую то идею.
Анрил и побыстрому раньше были несочитаемые вещи, может конечно что то да изменилось.
>>971210
Что "И"? Тебе написано это такая себе история
>это такая себе история
Потому что что? Потому что ты придумал себе что история была про стим, а история была не про стим?
>Анрил и побыстрому раньше были несочитаемые вещи
Там вся медленность из-за абстракции на абстракции - на каждый чих свой блядский эдитор и интерфейс, передавать данные туда-сюда это чехарда пиздос. Так что в этом плане да, быстро там делать тяжело. Но если геймджем длится не два дня, а две недели, то эта потеря в скорости уже не так решает. Но я погуглил и там две категории: 48 часов и 96, вангую анриловцы на вторую категорию идут. За 48 часов на анриле в принципе тоже можно, но там надо быть очень резким-дерзким и чувствовать себя в анриле как рыба в воде.
>Потому что что?
Потому что это статистика ради статистики. Какой из нее можно вывод сделать?
Типо ой можно за 3 дня собрать разваливающийся кусок кала и на годоте? (А то я не знал без этого круглешка)
Или настала неделя годота (количество высеров на гемджеме выросло)?
И еще 100500 тупых сравнений если желаете.
>За 48 часов на анриле в принципе тоже можно
Яб на такое посмотрел.
Как то я видел на твиче чувак на джем в 48 часов на юнити эвентах писал вообще все.
Ну естественно под конец у него начало все взрываться, я думал что и голова у него тоже лопнет.
>Какой из нее можно вывод сделать?
Объясни тогда, почему предыдущие 5 лет юнити стабильно 60% набирала, а теперь вдруг просела, пока остальные выросли. Случилось что-то наверное?
В чем вообще тут связь? в твоих фантазиях или что?
Че ты в шарады какие то играешь ты либо говори к чему ведешь либо иди обмазывайся своим джемом сколько вылезет
> Случилось что-то наверное?
Специальная суицидальная операция совета директоров Unity
>Яб на такое посмотрел.
На ютубе можно найти по запросу "3 devs make a game": https://www.youtube.com/watch?v=kk2VABmqWfA
Я не он, но можно предположить что популярность юнити просела после их прошлогоднего циркового выступления, что отразилось на статах для геймджемов, куда в основном индюки и стремщиеся высираются.
Я сейчас юню осваиваю и чесс говоря он отдает престарелостью. Годот, в свою очередь, сырой как лужа, но в нем ощущаешь себя комфортно и up-to-date.
Поэтому я склоняюсь к тому что Unity просто устаревает за неимением конкуренции за аудиторию самоделов.
>Я сейчас юню осваиваю и чесс говоря он отдает престарелостью. Годот, в свою очередь, сырой как лужа, но в нем ощущаешь себя комфортно и up-to-date.
Ну по сути так все и есть.
Годот свежее новее лучше и удобнее во многом, в некоторых местах ещё и проще.
Но как бы на юнити больше уверенности чтоли, инструментов больше, 3д адекватнее работает, с оптимизацией тоже попроще (если ecs не касаться там ад)
>Unity просто устаревает
Это тоже, но клоунада с платой за установки в прошлом году спугнула уже устоявшихся юнити-разрабов и настолько была расхайпана что даже не-разрабы были в курсе, так что репутационный ущерб ускорил процесс падения популярности, как по мне. Рикителло - герой опенсорса, ящитаю.
да щас 6 версию выкатят, если не обосруться то опять наберут популярность.
Дык Марк сам же ручками и делает. Судя по его видосам, он любитель пердолиться вручную и по сто раз переделывать одно и то же.
>Автоматизируй тряску
Там надо низкоуровневое нейропрограммирование знать. ща Илон Маск завезёт нейролинк, туда установяд ЖС и смогу просто библиотеку скачать.
Для новичков пойдет. Blu Ball - ригид боди, CollisionShape - его коллизия.
Area3D - отдельный треггер для чего нибудь, например хитбокса.
MeshInstance3D - визуал мяча.
А нельзя чтобы коллижншейп который юзается ригидбоди делал то что делает Ария3Д? А то чёт как-то грязновато выходит что у меня два колижншейпа.
Рассмотри ситуацию когда тебе надо сделать хитбос (ареа3д) больше по размерам чем физическая коллизия врага с окружением. С двумя шейпами ты это сможешь, с одним - нет. Или, например, ты делаешь врагу уязвимую точку анус и ставишь туда третий шейп малого размера. Так что все норм.
Area умеет детектить, когда в нее попадают другие Body или Area.
Body не умеет детектить, но умеет отскакивать от других Body. вообще умеет, но это не тема для новичков
Надо исходить из этих возможностей.
Например, ты можешь обойтись только RigidBody с CollisionShape, если ворота будут обладать своей Area для детекта гола.
Но если ты хочешь, чтобы два Body (например, мяч и футболист) детектили друг друга перед столкновением (ну может для спецэффекта, или для прилипания мяча к игроку), то у одного из них придется добавить и Area.
>грязновато
Для чистоты есть инкапсуляция - у тебя ВЕСЬ этот мяч будет в одной сцене, которой ты потом будешь пользоваться.
И че? Пока все сводится к тому, что ты сам себе выдумал, что джемы неправильно, и героически начал побеждать картинку про джемы.
Если не работает то значит что либо экшена такого нет в инпут мапе, либо бинд другой клавиши на нем. Че вообще за тупой вопрос, если у тебя код стопорится на какой то строке, тебе выдают ошибку где все написано.
Такого блять не бывает что вчера что то работало, а сегодня все сломалось хотя ты ничего не делал. Не пизди, а исправляй свои ошибки.
Исправил, не ори! Я думал в инспекторе что-то поменять мог, но там в другом причина была.
Нойс. Вот это наш слоняра. Не ноет, не ждёт ответов на вопросы по полгода. Берёт и делает, гугля по мере поступления проблем. И выкладывает в тред результаты.
Тебя задело что-ли? Там в соседнем тренде так же поражали над этой лабудой, так что мимокасы твои пирожки поехали
>может из за jolt'а?
Посмотри в настройках:
https://github.com/godot-jolt/godot-jolt/blob/master/docs/settings.md#jolt-3d
Как минимум, по умолчанию Area3D в Jolt игнорит статичные тела, из-за низкой производительности.
Я так глянул настройки jolt а, и видел этот пункт. Пробовал включить, стало детектить Статик боди, но мне то надо другую ареа3д детектидь.
Всё, определил в чём дело. Я на тот же сигнал, что детектид body смотрел. А для area3d свой сигнал.
>заморачивался готовя самодостаточные сцены - чтобы все их настройки устанавливались через экспорт-переменные
Да, так и надо делать с кастомными объектами.
>Надо поменять материал меша? Ставлю на родителя экспорт переменную и херачу код, устанавливающий ребенку новый материал.
Это имеет смысл если тебе часто нужно назначать материал снаружи. Однако, лучшим решением будет полностью абстрагироваться от концепции материалов, например, устанавливать не материал, а "тип персонажа", чтобы объект мог сам выбрать, какой материал ему нужен. Если ты явно кидаешь в него материал вместо назначения абстрактного "типа", ты по сути лезешь в чужую реализацию, создавая лишнюю зависимость от чужой реализации. У объекта должна быть подвижная ручка "выбрать тип" с делениями и подписями, а не пустая дырка для материала.
>Теперь я забил на это, добавляю сцену на уровень, включаю Editable Children, меняю что надо, группирую ноды через Ctrl+G чтобы случайно не выбрать ребенка вместо родителя, сворачиваю и еду дальше. Пока подводных не вижу.
Подводные:
1. Редактирование исходника вставленной сцены нарушает работу использующей сцены, поскольку она лезет в чужие кишки и зависима от них. Можно сломать так, что просто перечеркнёшь несколько часов работы независимо от того, есть у тебя гит/бекап или нет. Сам Godot может иногда спотыкаться при сложных манипуляциях в таких сценах.
2. Ты превращаешь сцены в тугой клубок лапши, которую тяжело понять, распутать и отладить, а потому становится сложнее расширять и поддерживать. По сути, так ты противоречишь основам ООП (объектно ориентированного проектирования), возвращаясь к неуправляемой лапше.
3. Сцены, в теории, грузятся дольше, т.к. ограничивается возможность переиспользования ресурсов в памяти. Вместо десятка одинаковых бойцов с разными enum в экспорте и одинаковым набором ресурсов внутри у тебя десяток частично независимых фрагментов сцены с кучей рандомных настроек в разных местах. Даже если нет ощутимой разницы, Godot по своей философии заточен на максимальное переиспользование всего, что можно. Фича с редактированием потомков такая же опасная, как доступ к рандомным нодам через get_node(), "синглтоны" и т.п. - они есть, но не предназначены для обмазывания проекта с ног до головы, т.к. нарушают базу ООП.
>хоткея на toggle visibility
А тебе зачем? Чувствую, что у тебя
https://ru.wikipedia.org/wiki/Проблема_XY
А почему тогда кнопочка в редакторе на toggle visibility есть? Чувствуешь ли ты, что у этой кнопочки проблема XY?
Поломка выглядит самым серьезным подводным камнем. Но пока не встречал. Встречу - буду думоть.
Проблема с остальными твоими советами - все это слишком муторно, долго и геморно, ради одного лишь одноразового изменения, которое понадобится единожды за всю игру. Да, таких изменений много, в разных сценах, но каждое из них нужно один, ну максимум два раза. Плодить ради этого энумы или наследовать сцены ощущается хуже чем лапша, ощущается будто в супе тонешь.
Использую, скрипты, реально, подводные сам C++, легко обосраться с порчей памяти.
Конечно, мне же делать нечего. Утомил расскажи что-нибудь поинтересней уже.
Ничего потаенного тут нет, это штатная возможность движка. Скриптовый язык для скриптов - штук, которые срабатывают изредка или один раз (например, когда прошел миссию в рпг).
У плюсов же несколько плюсов - они быстрее и гдскрипта и C#, при этом не тянут с собой рантайм .Net, они сложнее декомпилируются. Они подходят для числодробящих алгоритмов - например, часто используются в плагинах ремешинга террейна, или разрезания мешей объектов. В моем случае, я их использую для более быстрых переборов пошаговых ходов - это мой личный пункт, меня бесят пошаговые игры которые медленно считают. Плюс у меня ECS для логики, не для ускорения, а для удобства расширения механик. И до кучи, у меня клиент-сервер, где на сервере мне достаточно крутить только логику.
Ecs плюсы, да ты поди квадрупл А делаешь. Хотел бы я уметь хотя бы половину этого
А как писать плюсовые скрипты для годота? Он же вроде не родной язык как получается?
Предполагаю, что пишешь скрипт, делаешь из него .so с интерфейсами на гдскрипте, подгружааешь в проект
мимо
Бля пацаны у меня тут такой слом мировоззрения случился. Оказывается, Майнкрафт целиком на жабаскрипте написан. В смысле, вообще весь. Там вообще нет движка - только парочка графических библиотек и всё. Его даже исполняет тот жаба-интерпретатор, который есть у пользователя в системе, а не какой-то особенный.
Я раньше тоже рассуждал в таком ключе, мол, скриптовый язык только для скриптов. А тут такой удар в спину от самой популярной игры всех времён. И ведь ничо, норм летает на моём 10-летнем ноуте. Никаких проблем с тем, что вся игра написана на скриптовом языке.
> Java
> жабаскрипт
Завязывай с жирнотой
Алсо майнкрафт переписан на с++.
На джаве. Огромная разница с джаваскриптом. Из общего только слово Java.
>>971404
Переписан, но не заменен. Развиваются они оба, параллельно, джавовский до сих пор фичастей и считается основным.
Мочератор прикрепленного треда, насколько понимаю. Энивей, мы тут один из самых активных тредов, легко найти поскроллив нулевую.
Если видишь, что в треде 450+ ответов, то советую прокрутить немного вверх, с высокой вероятностью там будет написано сообщение ПЕРЕКАТ
В пезду, пойду поиграю, что ли
Теперь ты знаешь, что на одного конкурента у тебя меньше.
>В пезду, пойду поиграю, что ли
И на одного покупателя больше
>Алсо майнкрафт переписан на с++
Так называемый Bedrock Edition, в который играют полтора школьника? Туда моды не накатываются => не нужен. Подобные долгоиграющие проекты держатся исключительно на сообществе.
Хотя я в майн только на прошлой неделе вкатился, так что могу чего-то не понимать.
>>971406
>На джаве. Огромная разница с джаваскриптом. Из общего только слово Java.
Май бэд. Почему-то название Java Edition в моей памяти трансформировалось в JavaScript Edition. Проверил - реально жаба.
Хотя, с другой стороны, интерпретируемый байт-код, пусть даже со строгой типизацией, тоже та ещё залупа в сравнении с плюсами.
Лучше не понимать чем понимать, меньше знаешь крепче спишь. У меня часто передоз пердолинга случается что аж во сне продолжаю хуярить, такое состояние сном даже не назовешь ибо ты все четко слышишь что творится вокруг, это как осознанный сон, но ты будто в бреду, а в мыслях только поток строк кода которые ты еще и озвучиваешь в голове, и все это с ебать с какой скоростью. Вспомнился момент в трансформерах вторых когда он всю комнату своей шизой расписывал, это литерали то что происходит в бошке. Но есть и плюсы у этого состояния, весь шизокод придуманный во время такого сна работает идеально. Думаю Менделеев ловил такую же хуйню когда создавал таблицу.
> тоже та ещё залупа в сравнении с плюсами
Работа с физикой, с загрузкой ресурсов, моделей, тексур - будет идти дольше и тяжелее, чем интерпретация байткода.
Что будет лучше?
1. Забить пока на Godot и читать мануалы Python, из которого напрямую вызывать PyTorch и т.д. Потом, после обучения и тестирования нейронки, сделать интерфейс с игрой через HTTP, как раньше делал.
2. Подключать... какие-то ML библиотеки к Godot с GDExtension, чтобы делать всё прям на GDScript. Вроде видел уже какие-то аддоны на github...
3. Подключить Python к Godot для доступа ко всем библиотекам и следования туториалам, но в Godot.
Долго думал, склоняюсь к первому варианту...
>кнопочка в редакторе на toggle visibility
Visibility у нод обычно не нужно менять часто, уж тем более - в редакторе сцен. Если тебе приходится часто менять видимость нод в сцене - скорее всего, сцена выросла до слишком большого размера и её нужно разделить на несколько отдельных сцен. Серьёзное отличие Godot от Blender - Godot заточен иметь много вложенных друг в друга независимых сцен, тогда как Blender работает с единственной сценой, хотя и имеет возможность включать ресурсы из соседних .blend. Поэтому в Blender ты часто вынужден скрывать части сцены, а в Godot ты просто делаешь кучу разных tscn.
JIT почти стирает разницу между C++ и Java. Только для узких мест имеет смысл использовать нецтивнве либы, но я за год работы на проекте в общей сложности строчек 200 на крестах написал и порядка 30 000 на жабе.
Вот ещё немного подождём - будет JIT и у GDScript.
Я лично жду релиза 5.0 - чувствую, будет круто.
А потом ты начинаешь делать локации размером хотя бы с марио 64, и стройная гипотеза разваливается, и приходится тянуться к глазику на каждой ноде, с которой работаешь.
А потом ты ставишь вот это, https://godotengine.org/asset-library/asset/2645 и все дела. А проблема XY у тебя, когда узнал про умные концепции и пихаешь их везде не думая, и пишешь занудные посты, и строишь оправдания уровня "нинужно" вместо решения проблемы. Такие дела, анон.
>Помните скриншоты попыток прицепить LLM (Qwen)
Не помню, но сам хотел сделать подобное, узнавал про микромодели тоже
https://2ch.hk/ai/res/786469.html#792677
Я планировал делать на ТВГ, поэтому собирался просто запускать llama.cpp в режиме http сервера, чтобы любой мог скачать оригинал с сайта и не париться насчет вирусов.
Но llama.cpp вроде можно собрать в виде с++-либы и заинклюдить... https://github.com/ggerganov/llama.cpp/discussions/7631 Или как вариант запускать llama.cpp бинарник, но общаться с ним через pipe https://github.com/ggerganov/llama.cpp/issues/2161
Но я теоретизирую, на практике еще не пробовал.
Какая же красота, это весь код
>нинужен
И тем не менее C++ в 2-4 раза быстрее Java. Это же прямо идеальный бенчмарк, когда буквально одинаковую комплексную программу реализовали дважды на разных языках.
А сейчас он не джаст-ин-тайм? А почему тогда проект запускается моментально, без ожидания?
JIT подразумевает компиляцию в нативный код. Не припомню чтобы в годот был включен компилятор. Гдскрипт вроде бы превращается в какой то байткод, но он все равно интерпретируется.
Вообще как раз JIT бы и не запускался мгновенно, а сначала микрокомпилировался
Есть еще жестче способ. Тени окружения просто запечь (и забыть о динамических). Тень от персонажа выкинуть и заменить плоским кружком-спрайтом на земле. В вебе у меня банально иначе не получается выжать хоть сколько то фепесов.
> Тень от персонажа выкинуть и заменить плоским кружком-спрайтом на земле.
Между прочим так даже лучше, если подразумевается тридэ-платформинг.
Там есть нюансы с проекциями на ступеньки и прочие подпрыгивания.
А вот теперь то что надо!
Ну все, можно снова ждать.
Охренеть, там больше нововведений чем в юнити за последние 3 года
Ну ты сравнил, маленькую скромную юньку с 2.5 калеками в команде разработчиков и гиганта индустрии GODOT с его АААА проектами.
> учись быстрее, робот!
> приходится лезть в документацию и исправлять его
Ты ж его сам учишь. Сам себе роешь могилу.
Я не удивлюсь если конкретно над разработкой в юнити сидит 2.5 калеки, остальные гоняют чаи в HR отделе, обсуждают проблемы диверсити в DEI отделе, пока совет директоров придумывают как бы еще сильнее ускорить банкротство компании новой выходкой.
Заебись. Теперь уничтожай наименьший куб, а игрока запихни в лабиринт-пещеру и вот тебе майнкрафт.
Так и есть, когда юнитисрач был с лицензиями, в твиттере один бывший юнитиразраб писал, что они по пол дня могли про политику сраться. Большая компания с избытком денег, конкуренции особо нет, зачем усираться. Недавно новость была в газпроме про чела забыли, он не работал а зарплату 200к получал, всем норм.
Разработчик рассказал, что он заработал $500 тыс. в Amazon, не выполнив за полтора года ни одной задачи.
После сокращения в Google разработчик поставил себе чёткую цель: много денег и ничего не делать. Потом он устроился в Amazon.
Его план удался:
• 0 выполненных задач за полтора года;
• 8 рабочих часов. Это в неделю и в основном на встречах;
• 7 закрытых тикетов и 1 автоматизированная панель управления, которую он создал с помощью ChatGPT за 3 дня (но сказал, что это заняло 3 месяца);
• у него позиция старшего Technical Product Manager с зарплатой $370 тыс. (Senior TPM with 370k TC in MCoL);
• Amazon его работа устраивает и увольнять этого сотрудника никто не собирается;
• Его текущая ежедневная работа заключается в том, чтобы говорить «нет» другим командам, желающим интегрироваться с его командой или передать им 95%+ работы по интеграции.
Ты вроде взрослый, а в такие сказки веришь. Это сами гуглы-амазоны и сочиняют, чтобы попиариться, а потом заодно снизить айтишникам зарплаты и позакручивать гайки всякими KPI.
Да ладно, счастье ближе чем кажется, вон в России обычный Иван может зарабатывать 3800 евро в месяц без опыта работы и образования
Да не, я пару лет в крупной корпорации РФ работал, у нас тоже таких бездельников хватало. И это не моя нелюбовь к коллегам, они и сами осознавали что не делают нихуя. Некоторые свои хобби проекты пилили, другие вообще в вов на рабочем месте гоняли и "работали" так годами. Но это в сытые годы было. Как сейчас хз. На мой взгляд чем крупнее компания тем легче к ней присосаться и, затерявшись в толпе, пинать хуи. Представляю что творилось в каком-нибудь газпроме.
> Как сейчас хз.
У меня в кругу айтишники с гос. предприятий, которые целыми днями сериалы за зарплату смотрят. Пока рабочих сокращали еще в пандемию, их отделы не трогали.
Но там и контингент такой, одни дети руководства завода и чиновников от мала до велика.
> гос. предприятия
Работал в отделе где из 50 человек 30 играли в игры, читали книжки, пиздели в курилках и в кафешке весь день вместо работы. Начальник всё порывался всех уволить, но почему-то не получалось.
Ну потому что если у тебя народ по ТК, то ты хрен его уволишь.
>играли в игры
А могли бы делать. И вы делайте. Чтобы до 4.4 все по одной игре сделали.
>Гопота меня не скоро заменит
>учись быстрее, робот!
Для LLM типа ChatGPT документация по Godot - буквально капля в океане информации, на которой её (LLM) тренируют. Буквально, обучают на 100500 разных языков, библиотек и т.д. Представь себе человека с настолько широким кругозором. Его мозг был бы, наверное, размером с небоскрёб. Представил? А теперь попроси его вспомнить что-то из документации по Godot, которую он читал условно 15000 лет назад, если считать по объёму всех прочитанных материалов... Удивительно, как они вообще могут что-то внятно написать про Godot без дополнительных подсказок.
Полагаю, чтобы LLM могла генерировать точный и полезный код на GDScript, её нужно тренировать конкретно с этой целью, чтобы она стала больше похожа на специалиста, чем на всезнайку-буквоеда (лол). Но для полноценного программиста-разработчика ещё много чего не хватает.
>>971599
>Ты ж его сам учишь.
От таких диалогов с облачной LLM толку мало - лучше в Godot разбираться он не начнёт. Может даже испортиться, тем более что разработчикам из OpenAI должно быть решительно наплевать на каких-то там игроделов (кто-то гоняет бенчмарки специально на глубину знаний по Godot?)...
>Сам себе роешь могилу.
Так ведь Godot в основном для любителей, а любители идут в геймдев не ради денег или известности, а чтоб воплотить в жизнь игру мечты. Если какая-то программа может решить всю или большую часть работы - нам это должно только пользу принести. Тем же, кто рассчитывает заработать на своих игрульках - соболезную вне зависимости от достижений в сфере ИИ, потому что заработать на играх практически нереально (учитывая затраты на разработку, маркетинг и т.д., даже если вы всё делаете "бесплатно"). Зарабатывают торговые площадки и издатели, а не разработчики игр.
>Представь себе человека
Некорректное сравнение. Человечий мясной мозг заточен на энергоэффективность, поэтому нейронные связи, которые редко используются, ослабевают. Из-за этого когда мы вспоминаем то что не юзали много лет, у нас уходит много времени или вообще не получается, ибо мозг решил раз не юзаешь значит не надо. С искусственной нейронкой такой механизм если спецом не завезти, то этого не будет - сеть работает одинаково эффективно в любую сторону. Что кстати минус, ибо это ударяет по ресурсам.
>редко используются, ослабевают
Дело не в этом. Нейронку специально тренируют так (пикрил - посередине), чтобы она не могла выучить всё на свете наизусть, но зато могла применить общие шаблоны на незнакомых данных. А вот человеческий мозг, скорее всего, как раз заучивает наизусть практически всё, с чем встречается (пикрил - справа), потому что может себе позволить и потому что это выгоднее для выживания.
Но аналогия полезна в том плане, что ты пытаешься впихнуть в нейросеть то, что впихнуть туда в принципе невозможно. Веса нейронки весят, скажем, 100 ГБ, в неё запихивают объём данных массой 100 ТБ, получая сжатие, условно, в 1000 раз. А теперь ты хочешь узнать информацию из кусочка размером 10 МБ, который сжали, условно, до 10 КБ. Человеческий мозг тоже ограничен по памяти (хотя точный объём неизвестен и, скорее всего, очень велик) и если ты попытаешься впихнуть в него "всё на свете", глупо рассчитывать, что маленький участок будет сколько-нибудь точным - не из-за забывания по ходу дела, а просто потому, что ты впихуешь невпихуемое.
Тут возможно два выхода:
1. Сделать умника, который может мгновенно прочитать 10 МБ текста, проанализировать его, разобрать по полочкам и собрать из этого что-то другое, и всё это - не меняя параметров сети. Собственно, для этого и делают всякие ChatGPT, т.е. подразумевается, что ты должен сначала закинуть в него всю документацию и весь свой код и задавать его вопросы об этом. Бизнесу это очень выгодно, потому что они продают золотой молоток для любой задачи.
2. Сделать специалиста, который разбирается только в знакомой ему теме и способен быстро получать актуальные знания, чтобы без дополнительной информации точно решать задачи в знакомой ему теме. Но для этого, видимо, нужна какая-то неизвестная фича мозга. Или это тупо не выгодно изучать бизнесу (бизнесу уровня OpenAI, продающего ChatGPT всем на свете, ведь больше всех во время золотой лихорадки зарабатывают продавцы лопат).
Короче говоря, не ной и пиши код сам. А ещё рисуй, пиши сценарий, музыку, трейлер... лол.
Общая LLM может быть полезна на уровне проектирования игры, мозгового штурма идей. В этом плане информация более абстрактная, общая - не завязана на API малопопулярного инструмента, а значит, имеет бОльшую долю в обучающих данных и более серьёзную долю в параметрах сети, что должно означать более полезные ответы с меньшим числом ошибок. А вот обобщение API Godot с другими игровыми движками ведёт только к ошибкам для всех этих движков, особенно учитывая постоянные изменения и устаревшие сведения в обучающих данных.
>Короче говоря, не ной и пиши код сам
>А потом ты начинаешь делать локации размером хотя бы с марио 64, и стройная гипотеза разваливается, и приходится тянуться к глазику на каждой ноде, с которой работаешь.
Конкретно что тебе мешает вставить в сцену замок или разбросать монетки?
Ладно бы ты сказал:
>А потом ты начинаешь делать Гигахрущ в полную величину, и стройная гипотеза разваливается, и приходится тянуться к глазику на каждой гермодвери, с которой работаешь.
Но для этого как раз и нужно разделять большую сцену на маленькие. И загружать маленькие сцены динамически, когда игрок открывает дверь. А не копаться в гигантской сцене, постоянно тыкая на кнопку скрыть/показать.
>А потом ты ставишь вот это
И продолжаешь мучиться из-за того, что твоя сцена выглядит как окрошка из базовых нод.
>Но пока не встречал.
А я встречал несколько раз такое:
- есть сцена А с десятком нод, ничего особо сложного;
- есть сцена Б, использующая сцену А, немного сложнее;
- в сцене Б добавлены ноды к внутренним нодам сцены А;
- по какой-либо причине ноды в сцене А как-то меняются.
Что должно произойти, как думаешь? Интуиция подсказывает, что движок должен сохранить содержимое Б без изменений, даже если сцена А изменилась (т.к. ты видишь содержимое из А внутри Б, как будто это копия, но это не копия). Но на практике у меня движок просто-напросто игнорировал часть нод сцены Б, просто перечёркивая работу, будто бы её и не было совсем. Особенно обидно если это обновление произошло после реимпорта 3D модели, к костям которой я что-то прицепил через ноду RemoteTransform3D. Как минимум один раз мне пришлось доставать из архива старую версию этих сцен, чтобы перенести утраченные ноды из старой версии Б в "новую" версию Б, хотя изменения на самом деле касались только сцены А.
Легко представить, как ты можешь просто не заметить такой косяк, если у тебя большие сцены и ты не пересматриваешь их все после каждого изменения. Вот взял, изменил какую-то сцену, запустил игру - вроде всё работает, ошибок нет, но ВНЕЗАПНО что-то не так: кучки нод просто не существует. Начнёшь вслепую перекапывать сцены в поиске того, что ты потерял и почему. А как найти то, чего нет? Если не помнишь наизусть, что и где должно быть, придётся сверять со старой версией проекта. Лично я гитом не пользуюсь, но вряд ли сравнение текстовых файлов облегчит поиск, потому что в текстовом виде tscn слишком запутанные, и не факт, что эта "потеря нод" вообще видна в сцене Б, если ты её не сохранял (а вот если уже сохранил - тогда, вроде, ноды исчезают уже из файла), а изменения в сцене А не являются ошибочными (с точки зрения самой сцены А ошибки нет).
Честно, не знаю, баг это или нет, пофиксили уже или нет, и можно ли пофиксить. Однако эти грабли заставили меня избегать фичи "редактировать внутренние ноды". Лучше я потрачу больше времени на планирование сцены А, чем костылить что-то в рамках сцены Б, потом случайно/необдуманно менять сцену А и терять работу в Б, о которой я уже даже забыл.
>таких изменений много, в разных сценах, но каждое из них нужно один, ну максимум два раза
Звучит не очень. Можешь привести примеры таких ситуаций?
>хуже чем лапша, ощущается будто в супе тонешь
В чём "суп"-то? Смысл как раз в том, чтобы разделить проект на независимые компоненты, разложенные по уровням абстракции - они не смешаны в одной миске, а аккуратно разложены по блюдам - бери что хочешь, в каком угодно порядке. Движок даёт тебе ноды - это самый низкий уровень абстракции, как базовые ингредиенты. Из нод ты должен сделать сцены, которые описывают какие-то игровые сущности - бутерброды. Из этих сцен - сущности более высокого уровня - тарелки с бутербродами разных видов. Если ты хорошо спланировал разделение, то изменение сущностей низкого уровня не должно повлиять на сущности высокого уровня (и наоборот). Тарелка не должна внезапно взрываться и отравлять всех окружающих угарным газом, если ты заменил колбасу на сыр или поменял сорт хлеба булочки.
Например, ты сделал монетку, разметил её копии по сцене уровня, а у одной из копий сделал стоимость 25 вместо 5 (требует замены текстуры в одной из внутренних нод); далее ты решил, что монетка должна иметь анимированный спрайт вместо статичного - это изменение монетки не должно приводить в негодность сцену уровня, не должно влиять на поведение монетки со стоимостью 25. В твоём случае, ты как минимум рискуешь пропустить отсутствие правильной текстуры у монетки со стоимостью 25, т.к. движок сбросил её кастомизацию из-за изменения внутренностей её сцены. Чтобы этого избежать, тебе нужно поле, в котором можно ввести или выбрать сумму, а уже сама монетка выберет себе подходящую текстуру или анимацию - тогда вне зависимости от изменений монетки сцена с монетками не пострадает (до тех пор, пока ты не изменишь само поле "стоимость монетки", но это нарушает интерфейс объекта, чего следует избегать, в отличие от изменений внутренней реализации). Даже если у тебя во всей игре сейчас всего одна монетка со стоимостью 25, это не значит, что в будущем не будет связанных с ней изменений. А если ты забудешь, где она и что с ней (а ты забудешь) - рискуешь выкатить патч игры, в котором ты сделал всего лишь косметическое изменение, которое могло бы остаться незамеченным или за которое ты ожидал похвалу, но игроки теперь не могут пройти игру из-за сломанной монетки на одном из поздних уровней и жалуются на абстрактную "багованность", потому что им лень перечислять все баги, где и как они их нашли и т.д.
всё-всё, ухожу прикручивать мультиплеер к кнопке
Это только кода касается. Заливальщик поленился заменить арт/звук и получит бан.
>>971705
Я бы вам ответил, душнилы, но я давно уже поставил плагин на хоткей и половину локации наляпал сделал.
Да, я и тот который скрывает ноды, и редачит детей вместо готовки идеальных сцен. Я еще и детей скрываю тоже.
все, бросаю геймдев и удаляю все свои наработки, чтобы никто не нажился на моих трудах!!!!!!!!
>сам хотел сделать подобное, узнавал про микромодели тоже
А что именно ты хотел сделать? Чтобы игрок с NPC мог разговаривать?
Для начальных тестов лучше не возиться с компиляцией, а обращаться через HTTP запросы к какому-нибудь простому готовому серверу типа ollama или llamafile. Всё равно 99% времени ты ждёшь ответа от нейронки, так что никакие задержки сети не страшны.
Но проблема с LLM для игр в том, что без файнтюна или тренировки на игровом контенте свободно доступные модели будут вести себя совершенно не так, как ты, скорее всего, хочешь. Тем более - для взаимодействия между LLM и игрой, если NPC чуть больше чем чатбот (должен что-то делать или на что-то реагировать, учитывая это в своих репликах). Инструкциям в промптах они следуют слишком своенравно, и чем меньше параметров - тем, обычно, хуже. И заточка всех этих моделей на "послушного ИИ-ассистента" никак не помогает, а только вредит, если ты хочешь кого-то кроме "помощника".
Так что мои наивные попытки прикрутить что-то готовое к игре были заведомо провальными. Теперь я хочу попробовать обучать маленькую нейронку с нуля под конкретный контент, без вот этого вот всего LLM-ного... Понимаю, что успеха LLM не достичь и не превзойти, но для узких личных задач такая самоделка может быть лучше. Придётся дрочить питона...
https://2ch.hk/gd/arch/2019-12-27/res/524597.html
>>971765
В вашем случае пикрил - идеальное решение. А ради пиара стоит говорить что там нейронка, ИИ, самообучение, ЛЛМ и прочие модные слова.
У меня похожее чувство вчера было, не с игростроем связано, но я короче на второй плойке в свое время наверное, все игры прошел, а бог войны третий на третьей плойке вышел, и я тогда обломился. И все жил, услышу новость про бога войны, придет мысль поиграть, но то не до игр, семья работа, то денег не было, то просто не хочется, все думал как-нибудь я этих богов пройду когда-нибудь в будущем. Вчера раздуплился эмулятор ставлю, дай думаю пройду бв3, а игра оказывается аж 2010 года блин, это я 14 лет вату катал, время летит пиздец
Всё правильно делаешь.
В рантаймовом дереве нет никаких сцен, есть лишь одна сцена-дерево, в которой всё является нодами. Сцены, инстансы, автозагрузки - всё превращается в одно-единственное дерево. И если разрабу удобно, он может делать все вышеописанные трюки. И даже больше.
Например, можно инжектить скрипт в корень рантаймовой сцены-дерева get_tree().set_script(load("res://class_name_MySceneTree_extends_SceneTree.gd")) и в тот скрипт напихать сигналов и юзать его как шину сигналов. И доступ к этой шине будет предоставлен самим движком get_tree().new_game.connect(my_callback) раньше в трёшке это делалось отложенно, а в четвёрке сцена принимает вызовы к себе немедленно. Значит, разрабы в курсе о такой возможности и как минимум не мешают ей пользоваться. Защититься от случайного обращения к дереву до инжекта скрипта тоже несложно. Скрипту даём класснейм, как я указал выше, и просто без задней мысли хуярим ифы
if get_tree() is MySceneTree: get_tree().new_game.connect(my_callback)
>а обращаться через HTTP запросы к какому-нибудь простому готовому серверу типа ollama или llamafile.
В llama.cpp и так лежит http сервер: ./llama-server. Но, имхо, пайпы ничем не сложнее, а даже проще, линукс вэй и все дела. Запустил процесс и общаешься с ним, это даже меньше требует чем писать хттп клиент.
>Чтобы игрок с NPC мог разговаривать?
Я не эксперт в нейронках, но по опыту с гопотой, пофиг на файнтюн, можно много контекста загнать в промпт. В принципе, это же умножение входа на веса, P x M, так что тут можно считать, что данные могут быть как в весах, так и в промпте, от перемены мест условно результат то на то и выйдет.
> заточка всех этих моделей на "послушного ИИ-ассистента" никак не помогает, а только вредит, если ты хочешь кого-то кроме "помощника".
А, тут такой момент, в моем посте ссылки на модели с припиской -instruct. Это модели которые файнтюнили примерами "запрос? ответ" поверх базовой модели. А значит, можно и сами сырые модели использовать, или их -chat вариант.
>А что именно ты хотел сделать?
Просто поэкспериментировать. Например, команды для RTS. У меня была идея, что llm может генерить код по произвольной текстовой команде. Например, выбрать всех юнитов-стрелков. Или юнитов в красных беретах. Но код генерится долго и ненадежно. У одного чувака видел на хабре пример, как он генерит json команды. Сообщает в контексте какие есть поля, и нейронка генерит команду. Или у другого дядьки был пример генерации sql запроса из текста. А можно и дальше пойти, тут был старый тред где предлагали сделать эмерджентную ртс. То есть и сами способности и аттрибуты юнитов можно создавать нейронкой по описанию, а потом ими управлять. "Создай технологию тяжелых юнитов (+ в промпт идет контекст игры - какие уже есть юниты, какие могут быть технологии, требование соблюдать баланс)" - и она выдаст что то вроде "слонопотамы с пусковой установкой кристалбомб".
Вторая идея - концепция "бога-гейммастера". Это нечто, запускающееся периодично, например раз в 1-5 минут, и пытающееся понять, что вообще за ситуация, как ее можно описать. Например, игрок пишет команды "пойду в магазин и куплю удобрения". "Пойду в строительный и куплю металлических ведер". Нейронка может описать что он готовится выращивать овощи на ферме. Или может оценить что он планирует восстание. И двигать дальше сюжет в таком направлении.
Типизированные словари везут.
Бесплатные волонтеры. Ждем когда юнити выкинет сисярп в пользу гдскрипта.
Начнём с того, что речь шла не про рантайм... Если ты запутаешься в своём дизайне сцен, до рантайма на компе игрока твоя игра может и не дожить вообще.
Если так хочется усложнить себе жизнь - делай игру вообще без редактора, в одном скрипте, который будет делать всё обращениями к API. Но зачем это рекомендовать другим? Другим нужно советовать способы упростить жизнь, а не усложнить её.
>если разрабу удобно
>просто без задней мысли хуярим ифы
Если хочешь как ЯндереДев говнокодить - вперёд. Только учитывай, что ему крупно повезло зайти в никем не занятую нишу и собрать вокруг себя кучу пищащих фанаток, которые ему до сих пор бабки заносят несмотря на все проблемы с игрой...
Поучительная история так-то:
1. ЯндереДев, классический флиппер бесплатных ассетов на юнити, копипастит портянку из if-else.
2. Около сотни NPC каждый кадр проходят по этой портянке, проверяя, не пора ли им куда-то идти.
3. FPS закономерно падает в ничто буквально у всех, но хомячки уплетают аниме+кровь за обе щеки.
4. Игру декомпилируют и обнаруживают портянку. Обозревают, смеются, делают тысячи мемов.
5. ЯндереДев истерит, но потом соглашается нанять в качестве помощника толкового программиста.
6. Программист переделывает всё по правилам. Закономерно, игра становится лучше на глазах.
7. ЯндереДев снова истерит, что теперь код его игры стал ему непонятным, и выгоняет программиста.
8. Снова высмеивают на весь интернет, он просит прощения, обещает учиться программировать, но остаётся всеобщим посмешищем, бывшие фанаты конвертируются в хейтеров и ищут у него любые недостатки, чтобы подлить масла в огонь драмы.
Какова мораль сей басни? Если делаешь игру - делай качественно и снаружи, и изнутри. Никакие средства усложнения декомпиляции не защитят от позора... Конечно, если твоя игра кому-то будет нужна, так что Неуловимых Джо с их прототипами это не касается.
>везут
Даты видишь? Больше года везут. Хуан оценил, но это не гарантирует, что добавят в 4.4.
>>971827
>изобретают сишарпу
Скорее уж Python... Но оптимизированный.
>миллион человекочасов
Человеко-часы корпорации != время на разработку.
В корпорациях всё обычно намного медленнее.
>>971830
>юнити выкинет сисярп в пользу гдскрипта
Даже если и возьмут GDScript, это будет их личный форк. Так что для нас от этого никакой пользы. Но было бы неплохо отделить GDScript из Godot, чтобы можно было его как общий ЯП использовать. Сейчас ты можешь скрипт запустить БЕЗ игры только если у тебя есть игровой движок или шаблон экспорта.
На мой взгляд, единственный недостаток GDScript - его зависимость от движка. Но это было причиной его возникновения, так что вряд ли изменится.
Для твоих поучительных историй есть контрпример Тоби Фокса с его портянками иф-елсов, на которых он нахуячил мегапопулярный андертейл и его сиквелы. Понятно что это крайность, как и твои примеры. Суть в том, что всем похуй на твой код, а тебе должно быть похуй что кто-то там смеется. Всем ты никогда не угодишь.
Короче, чел, дыши глубже и не отвлекайся от своих мультиплеерных кнопок.
>Какова мораль сей басни? Если делаешь игру - делай качественно и снаружи, и изнутри
По мне так мораль - не будь ЧСВшным дауном и если тебе судьба прислала погромиста который принялся всё исправлять, то не мешай ему, а даже подсматривай и учись.
Неправильные выводы. У ЯндереДева поведение фриковое, поэтому его травят. Для понимания приведу тебе Терри Девиса. Не смотря на качественный код и неиронично потрясающие достижения форчеры его затравили до того что из дома выгнали, и, спорно, до суицида. Потому что фрик и шиз, не потому что код говно. Не будь таким, анон, не будь фриком.
>не будь ЧСВшным дауном
Как будто можно просто взять и измениться.
>не мешай ему, а даже подсматривай и учись.
Так ты поставь себя на его место. Ты несколько лет занимался проектом в одиночку. Выработал некую систему, привык к ней, она как продолжение тебя. И окружающие тебя хвалят, дают деньги. Приходит посторонний человек и кромсает твою систему на мелкие кусочки, делает что-то непонятное, по факту отбирает у тебя контроль за проектом, теперь любые изменения нужно с ним согласовывать. Негативные эмоции в такой ситуации более чем естественны. Но это не отменяет того факта, что твоя система - говно, серьёзно замедляющее разработку всего проекта.
>>971835
>мегапопулярный андертейл
Это из серии "так плохо, что уже хорошо". От какой-то стилизованной под древнее однобитное ретро игры многого не ожидаешь, работает и ладно. А Яндере замахивается на АААА симулятор школьной резни.
Суть в том, что если ты замахнулся на что-то хорошее, делай это хорошо. Если тебе лишь бы что-то высрать (игры с джемов, ассетфлипы) - тогда вопросов нет. В любой непонятной ситуации сначала лепишь из говна и палок прототип, выбрасываешь его, лепишь другой, третий, десятый. Но это не игры, к ним вопросов нет.
Ошибка ЯндереДева и ему подобных в том, что он на протяжении нескольких лет мял в руках прототипа кусок, а не разрабатывал полноценную игру. Вот и не делайте так. Слепили прототип, выбросили, делаете нормальную игру по всем правилам проектирования.
>>971838
>поведение фриковое
>не будь фриком
Да он обычный комнатный сыч по поведению. Или хочешь сказать, что в /gd/ все поголовно нормисы?
>не потому что код говно
Всё-таки говнокод сыграл свою роль. Полагаю, он затягивал с обновлениями не сознательно, а просто потому что добавлять новый контент тупо сложно, когда у тебя портянка ифов на десятки тысяч строк. Если бы он быстро разрабатывал игру, выполняя обещанное в срок, всем было бы глубоко насрать, какой он там по жизни человек. Народ ждал от него контента, а получил только отсрочки, отговорки и бесполезные побочные свистелки с перделками, которые банально проще вставить в говнокод.
Сравни, например, с Dwarf Fortress.
1. Никто не осуждает за длительность разработки, наоборот, хвалят за то, что не бросают проект.
2. Никто не обсуждает проблемы в их коде (глобально на весь интернет, высмеивая портянки ифов так, что Ютуб в рекомендациях выдаёт).
3. Никто не обсуждает их личности (глобально).
Почему? Потому что они доставляют обещанный контент. Я не знаю, как у них с кодом, но наверняка всё хорошо, раз удаётся стабильно поддерживать разработку столько лет. Говнокодер так бы не смог.
Или взять тот же Godot. Всего 1.5 шиза хейтят его из-за личной вражды с Хуаном, а в остальном движок хорош, потому что продолжает доставлять контент - в данном случае новые фичи, исправление багов, юзабилити. А %другойдвижок% топчется на месте и теряет юзеров, почему? Навалили говнокода и погрязли в нём (а кто конкретно виноват - СЕО или ещё кто - не суть важно).
Вывод: качество кода важно (в важном проекте).
>Так ты поставь себя на его место. Ты несколько лет занимался проектом в одиночку. Выработал некую систему, привык к ней, она как продолжение тебя. И окружающие тебя хвалят, дают деньги. Приходит посторонний человек и кромсает твою систему на мелкие кусочки, делает что-то непонятное, по факту отбирает у тебя контроль за проектом, теперь любые изменения нужно с ним согласовывать. Негативные эмоции в такой ситуации более чем естественны. Но это не отменяет того факта, что твоя система - говно, серьёзно замедляющее разработку всего проекта.
Если всё как ты описал, то да, но я думал что он его НАНЯЛ, а не просто какой-то хуй пришёл и начал хозяйничать нихуя не объясняя? Наверняка можно было обговорить что все изменения надо сперва обсудить, объяснить, задокументировать и потом приступать, причём совместно, чтобы ты понимал что зачем и почему.и помогал менять свою же кодовую базу. Но тут опять же надо ЧСВ подумерить и принять тот факт что ты не самый умный и что твой код всегда можно улучшить.
https://dtf.ru/gamedev/2947593-moya-igra-popala-v-top-100-na-samom-masshtabnom-geimdzheme-goda
>Everyone
Лол, что там? Три в ряд?
Ты где-нибудь сообщал об игре? Или просто залил в гугл и сидишь дома как сыч, ждёшь успеха? Хотя бы родственникам предлагал скачать?
Мне кажется, если у тебя там что-то достойное, 1к установок за год - это полный провал. Рандомы скачивают, возможно даже не люди, а боты.
Какую статистику сообщает гугл? Там вроде бы есть параметры удержания, средней сессии, запуски и т.д. Количество установок не так важно, как характер использования приложения пользователями.
У меня на копроигре в яи 500 уникальных игроков за месяц было, вот и думай.
>ради пиара стоит говорить что там нейронка, ИИ, самообучение, ЛЛМ и прочие модные слова.
Сейчас так не стоит делать. Generative AI вызывает животную ярость в некоторых обезьянах, особенно у рисовак и им сочувствующих. Steam требует от тебя объяснить подробно, как ты используешь "ИИ", иначе забанить игру могут, как и в случае с 18+ контентом.
Как и с 18+, в загон с ИИ стоит заходить только если действительно есть что показать. Иначе ты себе и видимость снижаешь, и ЦА свою не интересуешь.
>В вашем случае пикрил - идеальное решение.
Ты не понимаешь, на if-else разговорный ИИ делать чрезвычайно сложно. Почему у большинства игр - линейный сюжет без развилок, с псевдовыбором
>Согласен!
>Ладно, уговорил.
>(Просто кивнуть головой)
>(Молчание означает согласие)
? Почему даже в AAA RPG NPC ведут себя как тупые таблички с надписями, выдающие всего 2-3 фразы? Почему квесты - это "принеси 10 шкур волков"? И т.д.
Раньше было много разных попыток добавить в игру разговоры с NPC в произвольном формате. Однако, обычно это сводилось к поиску ключевых слов - если удалось угадать/узнать ключевое слово - получишь дополнительную реплику от NPC, что может помочь в прохождении какого-то квеста. Нормально общаться, а тем более заводить отношения не получалось.
Нейросети в теории могут с этим помочь. Что такое нейросеть? Это способ аппроксимации неизвестных функций. Мы знаем, что для того, чтобы ответить на заданную фразу нужно выполнить какую-то сложную функцию, которую выполняет наш мозг. Мозг, грубо, содержит миллиарды if-else, и мы не можем вручную повторить сколь-либо существенную часть из них. А нейросеть может приблизиться к некой упрощённой версии этой функции, сделать грубую модель того, что генерирует правильный ответ на запрос.
Практическая разница в том, что когда пишешь if-else вручную, ты своим мозгом создаёшь грубую модель некоторой сложной системы. Эта модель работает без примеров, сразу, как будет написана. Нейросети нужно предоставить примеры того, что ты хочешь получить - примеры сами по себе содержат в себе какую-то информацию о том, как их создавать, и нейросеть способна создать грубую модель системы за тебя. Выгодно это тем, что ты можешь создать миллионы виртуальных if-else автоматически, просто собрав достаточно примеров ввода-вывода. А дальше, если получится правильная модель, она сможет тебе генерировать что-то новое точно так же, как вручную написанные if-else, только теперь их миллионы, а не несколько десятков на каждую тысячу строк кода.
>>971791
>В llama.cpp и так лежит http сервер
Не знал. Я думал, llama-cpp - это только библиотека, которую нужно подключать, а "запустить" нельзя.
>линукс вэй и все дела
На Windows что делать будешь? На Android? С HTTP ты можешь скинуть нейронку на другой компьютер.
>это даже меньше требует чем писать хттп клиент
В Godot HTTP запросы очень легко делать:
https://docs.godotengine.org/en/stable/tutorials/networking/http_request_class.html
Суть в том, чтоб не возиться с низкоуровневыми API, а просто кинуть запрос и получить ответ. Потом, если получится что-то годное, переделать легко. Чтоб сфокусироваться на высокоуровневых абстракциях.
>по опыту с гопотой
ChatGPT? У него сотни миллиардов параметров.
>пофиг на файнтюн, можно много контекста загнать в промпт
Без файнтюна нейронке сложнее правильно отвечать, особенно если она "маленькая" (tinyllama). Из личного опыта и какой-то статьи, даже большие (70b+) могут игнорировать инфу из промпта и выдумывать своё. А у маленьких ещё и контекст мизерный: чем больше ты накидал инфы в промпт, тем меньше контекста на связное общение с игроком (цепочка сообщений).
>данные могут быть как в весах, так и в промпте
Как показывает практика - промпта недостаточно.
>модели с припиской -instruct. Это модели которые файнтюнили примерами "запрос? ответ" поверх базовой модели. А значит, можно и сами сырые модели использовать, или их -chat вариант.
Базовые модели - просто "предсказатель текста". И если твой текст не похож ни на что в интернете (или моделька маленькая и не знает ничего похожего), нормального предсказания от неё не получишь.
Кумеры из /ai/ не зря ищут файнтюны на эротику и ролевую игру. Потому что без файнтюна, даже если модель не отказывается от запроса, она просто не понимает, что от неё требуется, и никаким промптом нормально объяснить не получится. Если тебе нужен правдоподобный персонаж, а не бесформенная куча, слепленная из тысяч персонажей - тем более.
>команды для RTS
>выбрать всех юнитов-стрелков
Суть RTS примерно как у шутеров: скорость реакции важнее стратегического мышления. Пока ты вводишь текстовые или пусть даже голосовые команды, любой достойный игрок в RTS выиграет бой одной мышкой. Синглплеер? Разве что для инвалидов на приставках, которым неудобно мышкой выделять юнитов. Просто такие команды лишают игрока контроля над игрой.
>сами способности и аттрибуты юнитов можно создавать нейронкой по описанию
А как игра будет их интерпретировать? Сначала тебе необходимо разработать игру, в которой возможно создание произвольных юнитов. А потом уже как-то генерировать описание юнитов. Даже в полностью текстовой игре от простого текста толку мало.
>требование соблюдать баланс
С этим LLM могут справиться только на уровне "ну да, нужен какой-то баланс, делай". Они даже на простых математических задачах ломаются, а нужно что-то уровня таблиц с тысячами параметров в формулах. Однако, если делать свою нейронку, в теории баланс можно регулировать с её помощью (если сможешь сформулировать, что такое баланс конкретной игры).
>технологию тяжелых юнитов
>и она выдаст что то вроде "слонопотамы с пусковой установкой кристалбомб"
Хрень какая-то, уровня кнопки "сделать случайного персонажа" в редакторе персонажей. Условный Spore привлекателен тем, что ты сам своих слонопотамов сделать можешь и потом ими управлять, а не тупой генератор тебе выдаёт какую-то рандомную фигню...
>Например, игрок пишет команды "пойду в магазин и куплю удобрения". "Пойду в строительный и куплю металлических ведер". Нейронка может описать что он готовится выращивать овощи на ферме. Или может оценить что он планирует восстание. И двигать дальше сюжет в таком направлении.
Вообще не понял. В чём игра заключается? Это чисто текстовая игра (без графики, физики и т.п.)? Если это чисто текстовая игра, то движок тут не нужен, LLM выполняет роль игрового движка (с горем пополам). А если у тебя 2D/3D игра, то куда игрок вводит эти команды и как твоя игра поймёт решение LLM?
Главная проблема тут в том, что ты переносишь на обученную кем-то другим нейронку ответственность за играбельность твоей игры. Если вдруг эта нейронка ломается на чём-то в твоей игре - что будешь делать? Откажешься от фичи в игре, или разведёшь руками и скажешь, чтоб игроки терпели баг? Редактированием промпта ты можешь случайно что-то другое сломать, а проверить это сложно. Это, кстати, одна из причин критики LLM: внутри может быть "спрятано" нечто "спящее", вызываемое определённым запросом. В игре это может вести критическим багам.
Конечно, самодельная нейронка тоже не полностью безопасна... Но над ней ты имеешь больше контроля - легче будет что-то исправить. В т.ч. файнтюном - по отзывам игроков, например, как в тех же чатботах, либо по собранной статистике игровых сессий. Тоже преимущество нейросетей - вместо попыток лично разобраться в тысячах if-else, просто кидаешь статы прошедших сессий с оценкой "делай так" или "больше такого не делай" и нейронка подстраивается под это, улучшая игровой опыт для всех игроков. Геймдев 2.0, впрочем, у больших дядь такое 100% было уже давно.
А если удастся учить нейронку в рантайме игры - возможно создать 100% персональный опыт. Для какого-нибудь симулятора свиданий крайне важная функция, чтоб игрок чувствовал связь с персонажем, а не гонял по захардкоженным сюжетным веткам, подробно описанным в интернете, так что в игру бессмысленно играть, прочитав фанатскую wiki. По сравнению с классической процедурной генерацией потенциал у такой игры значительно выше. Впрочем, самообучающиеся в рантайме NPC были ещё в 90-х.
Скорее всего, это из-за Khronos Group - они заняли место в "Patron". А Re-Logic упали до Sponsor Silver.
А кто-нибудь из местных донатит Godot? Сколько?
>даже большие (70b+) могут игнорировать инфу из промпта и выдумывать своё.
За это вроде какой то параметр отвечает, температура что ли. На остальное некогда отвечать.
>Суть RTS примерно как у шутеров: скорость реакции важнее стратегического мышления. Пока ты вводишь текстовые или пусть даже голосовые команды, любой достойный игрок в RTS выиграет бой одной мышкой.
Ну так это бред в который скатились RTS именно из за микроконтроля вместо стратегии. В реале как раз командир задает общую канву и формулирует четкие приказы, а не бегает руко водить каждого по одиночке.
В конце концов, промптом тоже можно описать тактику, наподобие каждый юнит подходит на расстояние выстрела, пуляет и сразу отбегает назад.
>Хрень какая-то, уровня кнопки "сделать случайного персонажа" в редакторе персонажей.
Представь себе что ты говоришь нейронке: сегодня я хочу поиграть в ртс как стракрафт, только не про броники против лазеров, а про магопанк. Или стимпанк. И она будет придумывать подходящие юниты.
Делаем ставки, через сколько лет месяцев недель это перестанет быть фантастикой?
Уже работают в етом направлении, так что однажды в конце века все будет
https://vgtimes.ru/gaming-news/111724-uchenye-iz-google-pridumali-dvizhok-na-baze-ii-i-zapustili-s-ego-pomoschyu-doom.html
Вот так пока перепиливаешь свои кнопки под идеальную архитектуру в стотысячный раз, гугл уже нейронки генерирующие игры выкатит, и все твои старания отправятся на свалку вместе с тобой и твоими идеально спроектированными кнопками.
Прошу помощи в поисках туториалов по созданию гексагональных карт, желательно с рандомной генерацией
>Почему у большинства игр - линейный сюжет без развилок, с псевдовыбором
Потому что иначе придётся прописывать все сюжетные ветки до конца игры, и с каждым новым выбором их количество будет расти в геометрической прогрессии. А вовсе не из-за того, что реплик много.
>>971839
>Сравни, например, с Dwarf Fortress.
То-то Путнам охуел, когда увидел их код, и чуть ли не с нуля всё стал переписывать.
>>971811
Ну давай, открой кюрсфорж и покажи мне моды на бедрок эдишон.
>>971535
>Это же прямо идеальный бенчмарк
Не ну тут-то соглы.
Просто изначальный поинт был в том, что целая игра написана на интерпретируемом языке, и никто не умер. Конечно, компилируемый язык в разы шустрее, никто не отрицает. Но в целом никто не запрещает анону писать на гдскрипте то, что другой анон переписал бы на плюсах.
Ага и при этом механики у всего этого говна будут 1к1, как под копирку. Только цвет и форма фаерболов и брони юнитов меняться. А уж про баланс я вообще молчу.
И аудитория у всего этого будет, как у мобильного гейминга - имбецилы, которые хавают однотипные "три в ряд" игры и клоны майнкрафта за обе щеки.
Ничего уникального не будет, а труд геймдизайнеров, например, будет цениться еще выше, т.к. порог вката увеличиться, а свежих идей не будет
Правильно, пошел нахуй. Соевых снежинок и так уже много в геймдеве
>Ага и при этом механики у всего этого говна будут 1к1, как под копирку.
Потому что тыскозал? Компонентный подход тебе о чем то говорит? В том то и прикол, что в каком то сеттинге брони может не быть, а в каком то она будет работать по другой механике.
>А уж про баланс я вообще молчу.
Хехе, в том то и прикол, что в такой игре будет динамическое поддержание баланса. Ведь когда она дисбалансировалась, появится исследование следующей технологии, которая будет учитывать существующий расклад сил.
Ты хоть понимаешь, что "ИИ" (да, в кавычках) тупо пересобирает ответ на твой запрос из огромного массива заранее подготовленных данных? Он не придумывает ничего нового.
>динамическое поддержание баланса
Т.е. кривые попытки поправить кривой баланс. Знаешь, что происходит с такими играми? В них никто не играет и они перестают быть популярными, т.к. геймплей говно. Обычному игроку похуй на твои исследования, обычный игрок хочет тупа играть и тупа получать удовольствие
>А если у тебя 2D/3D игра, то куда игрок вводит эти команды
Выше был пример игры, где есть юниты (2д/3д) но при этом есть ввод команды (текстом/голосом)
Но вообще, введение Deus, который может понимать события в любой игре, в т.ч. 2д/3д, я вижу как философский камень, священный грааль который продвинет геймдев в следующую эпоху. Хотя для этого, конечно, надо больше ресурсов, на компьютер вижн и прочее.
Приведу пару примеров. Пример 1 - teabagging. Нейросеть может вычислить из простых описаний (присел над побежденным врагом), что это может расцениваться как жест неуважения.
Пример 2 - жонглирование оружием. Тут результат похуже, но gpt4 движется в нужном направлении (последний пик). Суть в том, что даже без контекста, нейросеть определяет, что это обходит механику ограничения на одно оружие в руках. В идеале тут бы я хотел, чтобы нейронка выдавала решение, приемлимое это действие или нет, если приемлимое - добавляла механику ношения двух оружий, если нет - придумывала как ограничить (в одном из ответов, она предложила увеличить кулдаун на бросок-поднимание)
>Ты хоть понимаешь, что "ИИ" (да, в кавычках) тупо пересобирает ответ на твой запрос из огромного массива заранее подготовленных данных? Он не придумывает ничего нового.
Прям как человек. В этом и суть - использовать модель нейронки как "сумму человеческих знаний".
>.е. кривые попытки поправить кривой баланс.
Других не бывает. Вообще я не видел ни одного пруфа что баланс достижим (кроме вырожденных случаев где все играют одинаковыми фишками - но и тут у белых в шахматах 1% преимущества).
> обычный игрок хочет тупа играть и тупа получать удовольствие
В этом и фишка - такая игра будет подстраиваться под игрока чтобы он тупа получал удовольствие.
>Главная проблема тут в том, что ты переносишь на обученную кем-то другим нейронку ответственность
Звучит как лютый вин. Не люблю ответственность. Что мне даст моя личная ответственность, кроме головной боли?
Речь была вообще не об этом, а об анализе действий игрока. Впрочем, это все уже какой то оффтоп.
>туториалов по созданию гексагональных карт
https://redblobgames.com/grids/hexagons/
>желательно с рандомной генерацией
https://redblobgames.com/maps/terrain-from-noise/
https://docs.godotengine.org/en/stable/classes/class_noise.html
>Не люблю ответственность.
Ты в любом случае несёшь ответственность за свою игру перед игроками. Если твоя игра - нерабочий клубок багов, можешь сколько угодно оправдываться тем, что это чужая нейронка виновата - ты в любом случае выкатил нерабочий клубок багов. И игроки будут занижать оценки твоей игры, а не какой-то там облачной нейронки. Наглядных примеров полно: игра ломается из-за какой-то там технологии от третьих лиц, а игроки поливают говном разработчика игры, который использовал эту технологию от третьих лиц.
>>972025
>динамическое поддержание баланса
Т.е. 50% побед? Только начинаешь уверенно побеждать, как игра специально бросает тебя в непроходимые для тебя условия и ты проигрываешь. А если не забросишь игру с горящей жопой после десятка поражений подряд, игра сжалится и даст тебе победить, специально выбрав унизительно лёгкие условия для твоей победы. Такого баланса в играх предостаточно и без нейросетей.
>>971980
>Уже работают в етом направлении
Там нейронка выучила дум наизусть после огромного количества часов игры в оригинальный дум. И тратит на симуляцию намного больше оригинала. Таким тупым способом новую игру не сделать.
>>971951
>она будет придумывать подходящие юниты.
Ещё раз, как твоя игра будет реализовать все эти придуманные нейронкой юниты? Мы о сегодняшних возможностях говорим (в контексте Godot), а не о гипотетической волшебной кнопке "сделай игру".
>>971948
>В реале как раз командир задает общую канву и формулирует четкие приказы, а не бегает руко водить каждого по одиночке.
В реале у командира свой начальник, который дал ему приказ захватить или уничтожить заданную цель. И этот реальный командир отдаёт приказы своим подчинённым не ради собственного удовольствия, а ради выполнения поставленной начальником задачи, иначе лишится своей должности или даже жизни. Смекаешь? Зачем тащить этот реализм в игру, если от него нет "фана"? Это просто реализм ради реализма получается.
>промптом тоже можно описать тактику
А можно описать:
>Эй, нейронка, сыграй за меня, мне лень.
Или просто посмотреть летсплей. Или вообще забить на игры и заниматься тем, что тебе не лень и всё ещё доставляет удовольствие, если RTS - это не твоё.
Какая-то высосаная из пальца проблема. Есть набор классических механик, они доставляют игрокам фан - нет, нужно прикрутить реализм, чтобы был реализм.
Кроме того, если нужно, чтобы нейронка управляла юнитами в стратегии - сначала стратегию сделайте, а потом будете тренировать нейронку в эту игру играть.
Сделал это через duck typing - тупо проверяю если у объекта коллизии есть метод on_slice() и запускаю его. Хз норм это практика или нет. Гопота предложил через ивент бас но имхо для этого случая хуйня подход. Может олдовые годотеры знают способ получше.
Заодно заебашил спавнер и сразу понял что я хочу чтобы кубы летели по прямой а не падали.
Плюс добавил невидимые стенки и настроил слои коллизий так чтобы кубы сквозь них пролетали, а игрок нет. Мне не надо чтобы игрок волновался о том чтобы упасть с платформы и концентрировался только на рубке.
а бля забыл ремукснуть
ДА БЛЯ! У меня сегодня день мелких проёбов. Сорян за музыку, забыл вырубить перед записью!
>Там нейронка выучила дум наизусть после огромного количества часов игры в оригинальный дум. И тратит на симуляцию намного больше оригинала. Таким тупым способом новую игру не сделать.
Это только начало. Через стопицот лет нейронки будут выучивать игры за 5 наносек в браузере и сразу же ебашить на ее основе новую по твоим промптам
А ну ладно, раз ты сказал, то не будем делать.
Честно говоря я поэтому смело и делюсь идеями, что NPC не поймут о чем они, и будут отвечать шаблонными ответами.
ХОЧУ НЕЙРОНКУ В ИГРЕ, НО КАК?
@
>А ВОТ ЧЕРЕЗ СТОПИЦОТ ЛЕТ...
>>972090
ЭТО УЖЕ НЕ RTS, А ДРУГОЙ ЖАНР
@
>ОЙ ВСЁ, НУ И НЕ БУДЕМ ДЕЛАТЬ
> У меня все.
Нет уж погоди. А как же динамика? Такой подход будет статичным. Ты не сможешь сделать дуновение ветерка на частицах при прохождении мимо них.
Хммм. А что если заранее подготовить карту с гексагонми-пустышками, но при загрузки уровня каждая такая пустышка по специальному алгоритму принимала бы определенный вид? Хм...
>заранее подготовить карту с пустышками
Зачем? Какую задачу решает это действие?
>по специальному алгоритму принимала бы
Какому? Сложность процедурной генерации уровней заключается в выборе или создании "специального алгоритма", что генерирует информацию уровня.
Сразу скажу, что одного шума Перлина недостаточно.
Клеточки расставить по сетке - тупо for x: for y: ...
>Партикли отлично оптимизируются
Оптимизации должны соответствовать задаче.
>>972125
>сделать дуновение ветерка на частицах
Такую мелочь даже заметить на экране сложно...
Вот >>972104, например. Тени еще выключай на лишней хуйне. Еще мультимеши используй. Больше сходу из своего не вспоминается, и вообще спать пора.
>столкнулись на практике, но о чём не говорят.
Если кто-то столкнулся - будут говорить.
Если что-то связанное с движком:
https://github.com/godotengine/godot/issues?q=is%3Aopen+is%3Aissue+label%3Aperformance
>>972274
>Тени еще выключай
Об этом говорят. Это буквально база геймдева, любой геймер знает, что в 3д играх первым делом нужно все тени вырубать, чтобы выжать максимум ФПС.
>Еще мультимеши используй
Об этом тоже говорят, а главное - мультимеши нужно использовать с умом, они не всегда приносят пользу. Рендеринг в 4.x отличается от 3.x: тысячи отрисовок одного материала больше не просаживают ФПС как раньше, а в мультимеше один материал на всех. Если локация замкнутая и игрок в центре мультимеша, производительность может даже упасть из-за того, что меши за спиной игрока продолжают рендеринг.
Я проставил мод для всех Area2D на олвейс, перехожу в паузу, код начинает выполнять GetOverlappingAreas() а он не выдает список
Не работает во время паузы что ли
Если закроешь игру то, внезапно, тоже выполняться не будет. Поставь process_mode always родительской ноде: https://docs.godotengine.org/en/stable/tutorials/scripting/pausing_games.html
Родительная нода контрол и так стоит на алвайс, я уже привык что ебаный годотя страдает от паузы
но блять прописываю геттри паузе тру, контрол свой код выполняет, ареа2д нет.
Как же меня заебал этот годотя. Реально движок онли для порно игр
Ты не в состоянии прочитать доку и выбрать нужное значение?
https://wdfiles.ru/1s7ln?ysclid=m0kiyp195t382483264
и исходники
https://github.com/PacktPublishing/The-Essential-Guide-to-Creating-Multiplayer-Games-with-Godot-4.0
https://fs4.oceanofpdf.com/OceanofPDF.com/Learning_GDScript_by_Developing_a_Game_-_Sander_Vanhove.pdf?md5=b3pXsd67f0sqm-kQnUg1yg&expires=1727850636
https://github.com/PacktPublishing/Learning-GDScript-by-Developing-a-Game-with-Godot-4
https://github.com/PacktPublishing/Godot-4-Game-Development-Cookbook
Нужно сделать спрайты персонажей не пиксильарт . Ну и какие программы посоветуете.
Сам склоняюсь к векторной, так как намного проще маштабируется под разные экраны. Программу думаю корел
Как вариант
https://libresprite.github.io/#!/
>>972408
На бесплатность все равно, благо торренты позволяют. Хотелось бы советов по поводу растра или вектора. Я правильно понимаю, что условные фоны лучше делать в растре, а те же спрайты в векторе?
Ну, как я понимаю, растр - гиф, пнг, жпг. вектор - свг.
По факту не набюдал векторных реализаций в играх. Как правило - пнг и жпг, по дефолту.
https://yandex.ru/q/question/pochemu_videoigry_ne_delaiut_s_vektornoi_f279ba22/?ysclid=m0klb1lfbh586427614
Поебать в чем. Вектор ты при импорте в проект настраиваешь и он импортируется с указанными параметрами, зумом и всем таким как пнгшка, по сути.
Ну и капча. Макаку за хвост таскал.
>GetOverlappingAreas() а он не выдает список
Похоже, этот баг или что-то с ним связанное:
https://github.com/godotengine/godot/issues/89615
Пулл реквест с багфиксом перенесён на 4.4:
https://github.com/godotengine/godot/pull/90276
>>972392
>Поставь process_mode always родительской ноде:
Разве это влияет на что-то? Если always, то нода обрабатывается независимо от родителя, нет? Если родитель always, то детям менять ничего не нужно - значение по умолчанию копирует родителя.
Просто это баг конкретно в Area2D.
Брат, я все сделал но все равно тебе спасибо
Там надо было PhysicsServer2D и его актив ставить на бессконечное выполнение
Кстати, а зачем тебе список коллизий во время паузы? По идее, во время паузы новых коллизий нет.
Что бы добавлять летающие окна во время паузы. Не держать же их просто не видимыми... А так пауза - добавил, пауза кончилась и удалил со сцены
НУ круто же!
>что вообще лучше для игры
>векторная или растровая графика?
Зависит от желаемого стиля графики, но видеокарта работает только с растрами и поэтому нужно либо вручную растрировать векторы, либо движок сам растрирует в процессе импорта, например:
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_images.html
>SVG (.svg) - SVGs are rasterized using ThorVG when importing them. Support is limited; complex vectors may not render correctly. Text must be converted to paths; otherwise, it won't appear in the rasterized image. You can check whether ThorVG can render a certain vector correctly using its web-based viewer. For complex vectors, rendering them to PNGs using Inkscape is often a better solution. This can be automated thanks to its command-line interface.
TL;DR: простой вектор можно импортировать как SVG, а для сложного лучше экспортировать графику в PNG.
>Нужно сделать спрайты персонажей
Персонажей, если хочется детальной проработки, рисовать лучше в растре (в высоком разрешении). Векторная графика удобна если тебя устраивает стилизация а-ля Flash игры из 00-х. В принципе, нарисовать в векторе можно что угодно, но чем твоя картинка детальнее, тем сложнее (особенно если ПК недостаточно мощный - векторные редакторы по естественным причинам тяжелее для процессора).
>Ну и какие программы посоветуете.
Krita поддерживает и растровые слои, и векторные - простую обводку и заливку можно сделать в векторе, сохраняется внутри .kra (по сути .zip) как .svg. Также поддерживается покадровая анимация. Интерфейс подобен Фотошопу, но заточен под художников. Есть шаблоны для текстур, куча кистей, фильтров и т.д.
Но для сложной векторной графики лучше Inkscape.
https://github.com/MewPurPur/GodSVG - но вот вам свг редактор для создания супер-оптимизированных свгшек, вплоть до редактирования их кода. Написан на годоте одним из разработчиков годота.
>летающие окна
Это что? Окошки как в ММОРПГ? Зачем им проверять пересечение Area2D? Они же никак не пересекаются с игровыми объектами (Area2D для игровых объектов).
>Не держать же их просто не видимыми
>добавил, пауза кончилась и удалил со сцены
Если ты про окошки меню, то лучше не удалять, лишь скрывать (visible = false). При желании ставить их на паузу через PROCESS_MODE_WHEN_PAUSED, если они занимаются чем-то на фоне, когда уже не нужны.
Почему так? Сами по себе ноды дешёвые. В дереве одновременно могут находиться сотни тысяч нод без проблем с производительностью, если они ничего не делают. Control ноды сами по себе пассивны, делают работу только если на них что-то повлияло. Загрузка, создание, добавление в сцену, удаление со сцены - занимает больше времени и в случае сложных меню может вызывать ощутимый лаг. Игрокам, по крайней мере лично мне, неприятно, когда меню/окна игры отнимают аж секунду или больше на отображение... Будто создаются с нуля со всеми текстурами. Так что лучше держать меню где-то поблизости, чтоб оно мгновенно отображалось по требованию игрока. Особенно если по геймплею важно открывать эти менюшки часто (инвентарь, крафт, справка и т.д.).
Конечно, если в твоём случае ситуация вынуждает избавляться от окошек - ладно. Но по умолчанию, я считаю, лучше их просто скрывать (visible = false).
>удалил со сцены
Кстати, на счёт временного удаления из дерева:
https://github.com/godotengine/godot-proposals/issues/10212
Хуан хочет упростить процесс временного извления нод из дерева - с кнопками в редакторе и API:
>Node.stash_child(chid: Node)
>Node.unstash_child(chid: Node, at_index: int = -1)
И т.д. Довольно популярная операция, оказывается.
>лоуполи моделек чуть сложнее примитивов
И будет у тебя игра чуть сложнее примитивов. Даже заставка "трубопровод" в Windows не так проста, как кажется на первый взгляд. Особенно художникам. А графика - это то, на что первым делом обращает внимание твой потенциальный игрок.
>"2д игры проще чем 3д" - самый большой развод
Смотря как на это смотреть. Если делаешь 1-в-1 по механикам, но с разным рендером: всё сводится к количеству разных анимаций и стилю. 2D обычно более стильное и впечатляющее, чем 3D, но сотни анимаций потребуют больше времени в 2D. 3D позволяет крутить камерой, но если механики полностью совпадают, то это просто не нужно. 3D модельку сложнее детализировать, натягивать на скелет и анимировать по 12 правилам анимации. Необходимы специальные знания для 3D, тогда как рисовать в 2D можно буквально на любой бумажке. Оптимизация 3D графики сложнее, чем 2D графики. Главное преимущество 3D: использование одной текстуры, меша, скелета, анимации и т.д. много раз.
Но 3D графику редко используют для точной копии 2D игры. Чаще всего 3D используют, чтобы получить больше разных механик, недоступных в 2D, и другую перспективу на виртуальный мир: вид от первого и третьего лица, прыжки, карабканье, 3D головоломки, объёмные структуры и прочее. Навигация в 3D как игрока, так и NPC. Манёвры в 3D пространстве. Все специфичные для 3D механики сложнее, чем то, что может предоставить даже самая сложная 2D игра.
Кроме того, нужно осознавать ожидания игроков. Заявленная как 3D игра вызывает обычно больше ожиданий, чем любая 2D игра в том же жанре. Если ожидания не оправданы - игру игнорируют, либо заваливают негативными отзывами. Да, несложно сделать 3D игру на примитивах без текстур, но это не то, что ожидает средний игрок, когда слышит "3D". Стилизованные игры в 3D выглядят специфично и обычно менее популярны, чем фотореалистичные. Нужно очень постараться, чтобы игра на простых примитивах добилась признания и популярности. А простая 2D игра может быть любима игроками за картинки и историю, даже если механики слабые; никто не ожидает от 2D игр фотореализма и/или переусложнённых трёхмерных механик.
Банальный вид от первого лица требует проработки деталей, которые в 2D с видом сверху вообще нельзя разглядеть даже с максимальным приближением; в противном случае, у тебя будет сплошная заливка на половину или весь экран, что просто дезориентирует в пространстве, а ведь 3D навигация сложнее игроку.
Т.е. в среднем 2D игры всё-таки проще делать. При условии, что не замахиваешься на что-то слишком грандиозное и/или если художник. 3D проще если согласен терпеть негативные отзывы игроков за примитивную графику и/или если программист с кучей интересных 3D механик в голове, которые оправдывают недостаток качественной графики.
Для новичков рекомендуют 2D, чтобы разобраться с базовыми принципами геймдева без необходимости учитывать глубину пространства, вращать камеру в редакторе сцен и т.д. А ещё накидать примитивные рисунки в 2D проще, чем в 3D. Но такие учебные проекты не предназначены для публикации.
Все так. Все дело в анимациях. 3д Анимации это просто, хотя долго. Потому что ты просто махаешь фиксированными конечностями, как у манекена. В 2д каждый поворот руки это рисование с нуля и пересматривание всех кадров на проверку плавности.
Так что за 2д надо браться только если:
Устраивает примитивизм (летающие треугольнички едят кружочки). Ну или чуть посложнее как на пик1. (и сразу для сравнения пик2 как такая игра выглядит тупо из лоуполи 3д ассетов).
Либо анимаций будет мало (аля JRPG, человечки выскочили в одной позе, ну может второй кадр для атаки мечом, все остальное делается тряской, партиклами)
Либо ты ниибаться 2д художник, но тогда такие вопросы обычно и не задают, а просто рисуют по 20 страниц набросков одного персонажа.
Либо лоурез пискельарт, просто потому что там брутфорсом можно перепробовать несколько вариантов натыкивания пикселей, пока не получится как хочешь.
Либо перекладная/cut out анимация, от которой все плюются (хотя в некоторых играх типа видрил логично использовать ее). Некоторые еще пытаются растягивать текстуры спайном, что получается еще кринжовей.
Так что получается что у 2д очень нишевые применения. (А там где не нишевые, часто вместо спрайтов это то же рендер 3д или ее обрисовка)
Еще в 3д навскидку меньше стилей. Ну реализм, ну ретро недореализм (psx), ну лоуполи либо аниме. Рендеришь, освещаешь и получается сразу что-то похожее. В 2д стилей в разы больше, в одном пиксельарте только куча видов обводок, куча подхода к контрасту, насыщенности, куча стилей от чиби до реализма. В рисованом тем более, никто даже названий стилей не назовет. И все это как то сочетать или разобраться как это нарисовать самому.
>3д навскидку меньше стилей
Это тролинг?берешь и моделишь/рисуешь текстуры любой стиль .Для примера можно посмотреть упоротые игры 00
Вот на вскидку примеров.
Эти ребята, создавшие эти шедевры, считаются гениями, и считается, что простой анон не потянет аналогичный уровень.
Ну попробуй придумай персонажей запоминающихся. Какой у них дизайн будет, одежда? Высрешь только что-нибудь унылое
>создавшие эти шедевры
Ну с дизайном квейка можно поспорить
Я не художник, я писатель (графоман, конечно же) могу только описать персонажей, словно хуй дрочёный в куртке пидора, на мосту стояли трое ветреным октябрьским вечером, смахивая редкие капли налетающего дождя с высоких воротников смотрели в тёмную, словно хуй дрочёный воду.
>я писатель
Дай совет как написать минимально ваябельный сюжет, движимый диалогами?
Я уже советовал не раз, в разных тредах. И ты наверняка видел. Описывай логические цепочки событий от конца к началу. То есть, создай концовки, которые ты хочешь, чтобы были, а затем от каждой из них постепенно поднимайся в прошлое к моменту с которого всё началось. Постепенно так у тебя и концовки органично вплетутся в разветвления. А твой игрок пойдёт по игре сначала и будет раскрывать для себя перипетии сюжета.
Этот же принцип работает для геймплея. (И ты во множестве игр можешь обнаружить его следы в виде пролога с полностью прокачанным ву-конгом, например).
Сначала ты проектируешь польностью прокачанный игровой контроллер-бог, который всё вокруг себя испепеляет нахуй, летает и проходит сквозь стены, но все абилки контроллера ты проектируешь регулируемыми или отключаемыми. А затем ты игроку даёшь контроллер с полностью выключенными абилками и раздаёшь ему по сюжету.
И вообще много где этот принцип работает.
>разными стилями.
Мгс/тихий холм под реализм
Алиса магии мультяшный
Квейк 2 под ржавую трубу
Для меня вполне. Инстанцированная сцена - это цыплёнок. Детеныш будущей сцены.
В любом случае, неизвестно, что там >>972539 происходит? Насколько глубока проблема XY?
>проблема XY
Я тебя найду и вырву на твоей клавиатуре кнопки X и Y. Х и У тоже.
Мы с тобой прекрасно знаем, что при реальной встрече ты уткнёшь глазки в пол и пройдёшь мимо, вырыватель комнатный.
Дыши глубже, трясун. Мы оба знаем что это утрирование, прост ты заебал свой ХУ повсюду пихать.
Во избежание циклических зависимостей, может быть?
>>972510
Первая квака охуенна, с этой её мрачной техно-готичной атмосферой. Шамблер и макака (забыл, как называется, прыгучий такой демон) так вообще задизайнены - моё почтение. И это в трёх с половиной полигонах.
>прост ты
Про проблему XY несколько человек ИТТ пишут.
>>972539
Я не знаю, в чём там причина технически, но эти инстанциированные сцены имеют целую кучу особенностей, так что ничего удивительного.
Если тебе это всё-таки зачем-то надо:
1. Создаёшь базовую сцену. Назовём base.tscn.
2. В файловой системе ПКМ по base.tscn.
3. Выбираешь New Inherited Scene.
4. ???
5. Сохраняешь как отдельную сцену, child.tscn.
Все изменения в base.tscn повлияют на child.tscn.
>пик1. (и сразу для сравнения пик2 как такая игра выглядит тупо из лоуполи 3д ассетов).
Такую 2D машинку любой ребёнок нарисует, а такой сложный асфальтовый каток в 3D сделать сможет только профессионал с многолетним опытом 3D и исключительно 3D моделирования. Плюс текстуры. Текстуры кто рисовать будет, если ты рисовать не собираешься? Говно нейронкой размазывать? Со стоков платные фотки воровать? Стилей в 3D можно придумать много, только их рисовать нужно уметь, а в 2D любая макака за еду нарисует столько, сколько ты натянуть на механики толком не сумеешь.
>3д Анимации это просто
>махаешь фиксированными конечностями
>как у манекена
И будут у тебя манекены вместо людей. И нет, захват движений актёра тебя не спасёт, если ты не актёр. А в 2D просто нужно нарисовать позы какие захочешь, произвольно, без сложного рига и жёстких костей.
Короче, хорошее 3D намного сложнее хорошего 2D, а плохое 3D хуже плохого 2D. Поэтому 2D проще 3D.
Капсулу нельзя рубить. Я даже... Просто посмотри на свой код разделения/разрубания мешей и подумай, что происходит при разрубании капсулы? Капсула это не меш.
Капсула это математическая формула, которая под капотом движка превращается в меш с заданным уровнем детализации.
И скорее всего уровень детализации оптимизируется под капотом же движка, чтобы не рисовать слишком много геометрии.
Просто посмотри на капсулу в редакторе и поищи там полигоны.
А ты её рубишь.
Делай капсулу в блендере из (12 * 7 = 84 полигона (что?? 12 на семь? Чтооо?) импортируй и режь.
>, а такой сложный асфальтовый каток в 3D сделать сможет только
Во первых 99% тебе не нужно делать каток, будет готовый.
Во вторых, такая техника делается элементарно из примитивов. Можно по чертежам, можно по конструктору лего. Суть в том что это рутинная работа, просто расположить детальки.
>Текстуры
Такие текстуры везде бесплатно раздаются тысячами.
>в 2D любая макака за еду
Манямирок. Покажи же нам такую макаку которая умеет рисовать именно стабильно в одном стиле нужное, а не как обычно, умеет рисовать пару фуррей в уродском стиле и все.
>А в 2D просто нужно нарисовать позы какие захочешь, произвольно
Ахаха. ПРОСТО.
Хорошее 3д намного проще хорошего 2д, а плохое 3д все еще лучше плохого 2д, вот и все. Поэтому 3д проще 2д.
Вообще гига-тупой аргумент, так как 2д ассеты тоже есть, 2д можно заригать так же само как и 3д в спайне или мохо или бесплатном драгобоунс. Можно так же само рисовать из примитивов. Как может быть 2д проще хорошего 3д, когда ты можешь просто отрендерить 3д в 2д?
>Вообще гига-тупой аргумент
Умней, чтобы для тебя это не было тупым аргументом, потому что мне по кругу сейчас придется объяснять все второй раз.
> 2д ассеты тоже есть,
Да они есть, но в сотнях несовместимых арт стилях, и качество зачастую ужасное даже за деньги. В результате контент фрагментированный и на практике даже банальную локацию типа деревни ты в 2д хрен соберешь.
> 2д можно заригать так же само
Нет, это не так же само, результат таких 2д анимаций намного хуже, потому что они работают уже с проекцией в 2д и не обладают нужными степенями свободы, ты не заанимируешь там разворот из бега вправо в бег влево, руки ты можешь только поднимать а не вращать вдоль оси (как при открывании двери ключом например), плюс неизбежные артефакты от вращения по пиксельной сетке.
> Капсула это не меш.
>Капсула это математическая формула, которая под капотом движка превращается в меш с заданным уровнем детализации.
Но зачем? С циллиндром тот же прикол?
> Но зачем? С циллиндром тот же прикол?
Если их использовать для коллизий, получается очень быстрый расчёт по формуле. Если их использовать для визуала, получается гладкая фигура (как именно происходит построение визуального меша - надо смотреть в коде).
И так во всех движках или чисто в годоте? Просто по-моему я уже рубил капсулы в других движах, или мне кажется...
Вообще ты уверен что мы про одно и то же говорим? Просто тут вот вроде написано что это Meshinstance3D
Что значит рубил? В годоте такого функционала вроде нет, ты какой то адлон использовал или самописный? Там был какой то аддон то ли на шарпе то ли на плюсах.
https://github.com/SirLich/gd-explorer
Недоделан, но выглядит полезным и перспективным
>Капсула это математическая формула, которая под капотом движка превращается в меш с заданным уровнем детализации.
>Делай капсулу в блендере
Да ты упоролся. Не нужен блендер, всё просто:
https://docs.godotengine.org/en/stable/classes/class_primitivemesh.html#class-primitivemesh-method-get-mesh-arrays
В его случае достаточно снизить число полигонов в настройках капсулы, тогда будет меньше тормозить.
>>972649
>Попытался разрубить капсулу вместо куба
Там просто дохрена полигонов по умолчанию.
>3070 на борту
Тот плагин разрезает меши на одном ядре CPU.
>>972660
>Если их использовать для коллизий
Капсула для коллизий - это отдельная система, не связанная с визуальной капсулой-мешем.
>для визуала, получается гладкая фигура
Там по умолчанию дохрена полигонов, вот и всё.
>как именно происходит построение визуального
Просто полигональная сетка строится. Всё.
>>972669
>И так во всех движках или чисто в годоте?
Не слушай этого дурачка, он скорее всего тролль.
>дохрена полигонов по умолчанию
Если быть точным:
https://docs.godotengine.org/en/stable/classes/class_capsulemesh.html
>radial_segments = 64
Это число делений в обхвате капсулы. Хватит 6-8.
>rings = 8
Это число делений по длине капсулы. Хватит 2-3.
Итого... Не уверен, но где-то около 512 квадов? И, соответственно, около 1024 треугольников. На практике может быть ещё больше, я не считал.
Интересно:
https://github.com/godotengine/godot/issues/20030
Пикрил оттуда. Как видите, сетка слишком плотная.
>выглядит полезным и перспективным
Не понял, в чём там смысл? Локальная библиотека?
Давно ведётся обсуждение того, чтобы сделать все аддоны независимыми от проектов. Но, говорят, это сложно реализовать и сломает совместимость.
Godot 5.0 обещает быть интересным...
>CSGMesh
При чём тут CSG? Он медленный и глючный.
>перегоняется в обычную меш
CapsuleMesh тоже легко перегоняется в обычный.
При том, чтобы создать лоу-поли капсулу в годоте не нужен никакой блендер. Создаешь через CSG, перегоняешь в обычный меш и режешь. Потому что любому очевидно что дефолтная мешинстоновская капсула слишком хайполи для разрезов.
>не нужно делать каток, будет готовый
>текстуры везде бесплатно раздаются
>можно по конструктору лего
Ааа, так ты ассетфлипер, так бы и говорил. У тебя получится поделка как у ребёнка из Лего. Это бред, продавать уже собранные Лего-поделки, не так ли? Обычно ты покупаешь набор и собираешь сам себе удовольствия ради, а не чтобы заработать на этом.
>делается элементарно из примитивов
И получается элементарная хрень из примитивов.
>по чертежам
Ты их сначала найди, уникальные чертежи-то.
>рутинная работа, просто расположить детальки
Рутинная работа, просто нарисовать картинки.
>пару фуррей в уродском стиле и все
Да уж лучше уродских фуррей, чем ассетфлип.
>Хорошее 3д намного проще хорошего 2д
Только если ты ассетфлипер и делаешь только то, что сделано до тебя 100500 раз из тех же ассетов.
>а плохое 3д все еще лучше плохого 2д
Плохое 3Д неиграбельно, в отличие от флеш-игр.
>>972657
>но в сотнях несовместимых арт стилях
>качество зачастую ужасное даже за деньги
>плюс неизбежные артефакты
Так ты ж ассетфлипер, т.е. говноед, тебе и так сойдёт. Зачем париться, если игроки сожрут любое говно, по твоему ассетфлипскому мнению? Ты ж наверняка не игры делаешь, а симуляторы просмотра рекламы.
Короче, все твои аргументы сводятся к:
>В 3D много ассетов для флипанья говноподелок
>В 2D мало ассетов и аудитория менее говноедская
>Создаешь через CSG,
>мешинстоновская капсула слишком хайполи
Ой, всё. Ты не понимаешь, о чём вообще речь.
>посты читать
Хотя бы документацию читай.
CSG:
https://docs.godotengine.org/en/stable/classes/class_csgmesh3d.html#class-csgmesh3d-property-mesh
Instance:
https://docs.godotengine.org/en/stable/classes/class_meshinstance3d.html#class-meshinstance3d-property-mesh
Оба принимают один и тот же ресурс:
https://docs.godotengine.org/en/stable/classes/class_capsulemesh.html
Ага, хочется удобнее копаться в ассетах скачанных тоннами с sketchfab и itch.
Блять, не доглядел! Rings должно быть два (2). Иначе магия не сработает.
Ты кого обмануть пытаешься?
https://docs.godotengine.org/en/3.1/classes/class_csgmesh.html
https://docs.godotengine.org/en/3.1/classes/class_meshinstance.html
https://docs.godotengine.org/en/3.1/classes/class_capsulemesh.html
>В обычном программировании как-то легче
В каком "обычном"? В обычном всё точно так же:
https://ru.wikipedia.org/wiki/Инверсия_управления
GUIшные фреймворки работают как игры здесь.
>надеюсь будет норм
Да, привыкнешь к базовым концепциям и норм.
>Тот плагин разрезает меши на одном ядре CPU.
Тогда может в этом и проблема?
>>972803
>Итого... Не уверен, но где-то около 512 квадов? И, соответственно, около 1024 треугольников. На практике может быть ещё больше, я не считал.
Это всё равно хуйня, ибо я плотную скелетал меш анриловскую рубил на 100к+ квадов, но там функция рубки меши нативная, видать там не через одно ядро ЦПУ всё делают.
> Не слушай этого дурачка, он скорее всего тролль.
Надо переписать плагин под мультитрединг.
> var thread = Thread.new()
> thread.start(my_job_func)
мимо тот дурачок-тролль
>thread.start(my_job_func)
Про мультиплеер не забудь, race condition, кнопки...
О да. Мультиплеерные кнопки с мультитредингом - это будет пушка!
Для самих уровней понятно, есть куча алгоритмов - BSP-деревья, туннелирование, клеточные автоматы и т.д. и т.п. Огромное кол-во подробных статей и на русском, и на английском.
А что делать с наполнением уровня? Ну вот использую я, например, BSP-деревья. Некоторые комнаты можно даже "волекером" сгенерировать, чтобы было интереснее. А дальше? А что дальше - нигде не сказано. Нашел об этом краткую инфу только в этой статье (пик 1): https://habr.com/ru/articles/333692/
Как расставлять противников, ловушки, лут? Как обставлять интерьер комнаты? Так, чтобы все это размещалось логично. Можно накидать рандомно, но это превратиться в неправдоподобное месиво.
Можно попробовать решить это заранее заготовленными комнатами, но думается мне, что это не лучшее решение.
Конечно можно самому все продумать, написать логику с нуля, но это ебанешься. Может есть какие-то туториалы с основными моментами?
Делай как в твоей любимой игре, которую ты мечтаешь повторить.
>Как расставлять противников, ловушки, лут? Как обставлять интерьер комнаты? Так, чтобы все это размещалось логично.
Для мобов правила, кол-во на локации
Для ловушек, лута - соответствие условиям
Интерьер - так же, условия с готовым описанием и вариациями.
Хз смотри майн, генерации данжей, условия появления этих данжей ну и тд.
По ссылке ограниченны условиями генератор, в определённой зоне может по условиям появиться или одно или другое.
С меня, как всегда нихуя.
>генерировать контент внутри уровня
Отвечаешь сам себе на вопросы вроде таких:
- зачем игроку проходить уровень?
- в чём фан прохождения уровня?
- что игрок должен получить?
- какие испытания пройти?
И т.д. Избавляешься от неопределённости.
Тут хорошо может помочь чатбот, только попроси задавать тебе больше наводящих вопросов по теме.
На основе ответов, строишь общий цикл уровня:
... -> зашли -> изучаем/бьём мобов -> вышли -> ...
Дальше добавляешь вариации в этот цикл, создаёшь вложенные циклы для отдельных комнат, ловушек, особенных противников и т.д. Лучше всего, чтобы они все были взаимозаменяемыми.
Суть процедурной генерации не в том, чтобы игра придумывала контент вместо тебя. Суть в том, чтобы перетасовать колоду карт, которые ты заготовил для игроков. Определись с тем, что есть в колоде карт, и процедурную генерацию будет легче реализовать.
Даже в Майнкрафте есть эта колода карт - биомы и связанные с ними сущности. Без биомов генерация слишком скучная, весь интерес - изучать биомы, заготовленные вручную разработчиками. Генератор только перетасовывает расположение биомов и их содержимого (деревни, сундуки, входы в пещеры).
В целом, генерация - про контроль случайности. Если полностью случайно закрасить все пиксели экрана, получится бессмысленный шум. Полностью случайно расставить тайлы - будет шум из тайлов. Полностью случайно расставить куски карты - шум из кусочков. Вопрос в том, на каком уровне тебе нужен этот шум, в каком количестве, в каком виде. Создай полностью вручную один уровень и подумай, где тут нужен шум? Можно тасовать колоду, можно тасовать несколько, можно тасовать колоды из колод... Шум на разных уровнях приводит к разным результатам, но в основе всегда лежит заготовленный вручную контент.
> зачем игроку проходить уровень?
Чтобы прокачаться на пути к финальному боссу.
> в чём фан прохождения уровня?
Монстров весело постреливаешь. С неписями весело общаешься.
> что игрок должен получить?
Ресурсы и экспу.
> какие испытания пройти?
Да.
интерьер комнаты можно обставлять автоматом с правилами, или графом.
Автомат с правилами скорее всего однопроходный или малопроходный (не требует сотен поколений как клеточный). Можешь посмотреть например редактор LdTK. В примере, факел ставится в клетку над полом, вокругой которой ничего нет. А синие камушки - в клетку над T, то есть над полом в 2 толщины (не мостиком), и не над углом/краем платформы, + там рандомизатор спавна. Это можно совместить с упомянутым тобой бюджетьом.
Вариант с графами, это генерация графа уровня, она описана во всяких пейперах. Желательно это совместить с генерацией пещеры, как то. Объекты распологать в комнатах.
> факел ставится в клетку над полом, вокругой которой ничего нет
*уточнение, на этом слое.
Ну вот, видишь. Генерируй на карте:
- монстров
- торговцев
- ресурсы
- испытания
Осталось придумать, как они будут выглядеть.
>>972887
>факел ставится в клетку над полом
Как я понял, у него нет факела. Только комнаты.
На пике я показываю пример из ldtk, где факел ставится по правилу, на этапе после расстановки стен. А стены могут создаваться с комнатами.
Это можно и для другого приспособить, расставлять вдоль стен шкафы с книгами, верстаки, стойки для оружия, в центре комнаты столы, вокруг них стулья и т.д.
Вкратце, у нас тут техника Shadow Mapping, а в нулевые использовали Shadow Volumes. Маппинг дешевле, чем объёмы, потому что не требует создавать геометрию, однако объёмы позволяют делать более чёткие тени.
https://en.wikipedia.org/wiki/Shadow_volume
>Shadow volumes have become a popular tool for real-time shadowing, alongside the more venerable shadow mapping. The main advantage of shadow volumes is that they are accurate to the pixel (though many implementations have a minor self-shadowing problem along the silhouette edge, see construction below), whereas the accuracy of a shadow map depends on the texture memory allotted to it as well as the angle at which the shadows are cast (at some angles, the accuracy of a shadow map unavoidably suffers). However, the technique requires the creation of shadow geometry, which can be CPU intensive (depending on the implementation). The advantage of shadow mapping is that it is often faster, because shadow volume polygons are often very large in terms of screen space and require a lot of fill time (especially for convex objects), whereas shadow maps do not have this limitation.
https://godotengine.org/article/submissions-open-godot-2024-showreel/
Ну вот есть у меня мейн сцена, в ней кнопка, лейбл и спрайт.
Например мне надо повернуть спрайт и отобразить в лейбле количество градусов.
Я могу:
1. отправлять все pressed сигналы кнопки в мейн скрипт, а там уже всё делать
2. добавлять скрипт для всех, кому надо реагировать на кнопку, там подписываться на неё и уже в себе менять себя по нажатию в соответствующем обработчике
Не берём какие-то крайние случаи и реализацию, или кастомные сигналы и т.д.
Второй вопрос: насколько нормально вообще использовать вещь типа get_node(^"../Button") - в случае например второго варианта при коннекте в скрипте к кнопке?
Если есть возможность, не делай ../, не иди вверх по дереву, иди вниз. Вложенным нодам лучше не знать ничего о структуре проекта, им надо заниматься своим делом. Более внешним же позволительно знать про дочерние, они их насоздавали и они ими управляют.
Алсо необязательно делать это в мейн скрипте. Для этого можно сделать отдельную сцену-компонент.
>Для этого можно сделать отдельную сцену-компонент.
Я пока не дошёл до этого, не понимаю особо, что это.
Как тогда коннектиться с сиблингам. Например баттон эмиттит сигнал прессед. как его соседям на него подписаться? через гет_парент.гет_чайлд? Это же всё равно поулчается переход вверх.
>мейн скрипте
Тут я скорее имел ввиду просто парент ноду, структура такая
Parent(или Main)
|-Label
|-Button
|-Sprite2D
Ну т.е. первый вариант получается? Отправлять всё в родителя и там манипулировать?
Я не очень хочу, хочу чтобы они сами себя модифицировали, а не родительский скрипт.
Ну или я снова не понял. Объясни пож.
- заполнить всё от горизонта до горизонта по низу;
- адекватно проходить сквозь облака камерой;
- чтоб они плавно снижали видимость внутри;
- чтоб были максимально эффективными;
- желательно отображать потоки воздуха.
Что пробовал:
Volumetric clouds гуглил - не то.
Sky шейдер рисует только фон.
Встроенный дым очень дорог.
Геометрию создавать дорого.
Particles вообще не подходят.
Древний трюк с текстурами? Вроде не пробовал.
Но текстура понадобится просто колоссальная...
Неужели просто напердеть облаков так сложно?
>Submissions close on November 1st 2024 at 10:00 UTC
Самое время начать откладывать разработку игры.
Да не, ты все правильно делаешь, и голова у тебя соображает судя по всему. Пока делай как делается. просто пробуй разные варианты, со временем поймешь что тебе удобней.
>мейн сцена, в ней кнопка, лейбл и спрайт
Ты слишком абстрактный пример приводишь. Про мультиплеер забыл, например, где мультиплеер?
>Например мне надо повернуть спрайт и отобразить в лейбле количество градусов.
Если тебе нужно только это, тогда делай вообще как пожелаешь, разницы никакой нет. Ты этот код нигде не будешь использовать, поэтому не важно, как делать. Повторюсь, слишком абстрактный у тебя пример.
>get_node(^"../Button")
Как уже сказали - так лучше не делать. Система нод идеальна когда отдельные ноды и ветки нод можно произвольно передвигать, удалять и добавлять. Да, иногда это невозможно, но нужно стараться избегать лишних зависимостей от предка/соседей/внуков. Так что обращаться лучше только к своим личным детям.
>>973020
>Как тогда коннектиться с сиблингам.
Конкретно зачем тебе это нужно? Обычно, если очень нужно соединить соседей, лучше это делать через отдельное меню в инспекторе нод редактора, там ты выбираешь произвольную ноду в дереве, вводишь название функции, добавляешь аргументы и т.д. Т.е. через код соединять ничего не нужно, пока ты не добавляешь какие-то ноды/сцены из своего кода.
>>973023
>Я не очень хочу, хочу чтобы они сами себя модифицировали, а не родительский скрипт.
Почему не хочешь? Чего ты хочешь добиться?
Разберём конкретный пример, сцена персонажа:
- Player: CharacterBody2D
- - Shape: CollisionShape2D
- - Skin: Sprite2D
- - Animator: AnimationPlayer
- - HitBox: Area2D
- - - Shape: CollisionShape2D
- - HealthBar: ProgressBar
Ты в редакторе соединяешь area_entered от HitBox к Player, и пишешь примерно такой обработчик:
func _on_hit_box_area_entered(area: Area2D) -> void:
_ if area is Bullet: suffer_damage(area.damage)
Далее нужно что-то сделать с полученным числом:
func suffer_damage(amount: float) -> void:
_ health -= amount
_ if health <= 0:
_ _ health = 0
_ _ die() # анимация смерти и т.д.
_ health_bar.value = health
Тогда HealthBar просто отобразит новое значение.
Теперь допустим, что ты хочешь добавить анимацию изменения значения HealthBar. Ты мог бы сделать это внутри suffer_damage у Player, но вдруг ты захочешь добавить HealthBar к другим сущностям? Нужно абстрагировать анимацию HealthBar от Player.
Поэтому ты создаёшь новый скрипт, health_bar.gd:
var tween: Tween
func animate_to(new_value: float) -> void:
_ if tween: tween.kill()
_ tween = create_tween()
_ tween.tween_property(self, "value", new_value, 0.2)
Далее, в скрипте игрока ты можешь сделать так:
_ health_bar.animate_to(health)
Но тогда ты завязываешь скрипт Player на интерфейс HealthBar. Если переименуешь animate_to, придётся изменить и скрипт Player, а сначала найти эту строчку.
Поэтому ты можешь объявить новый сигнал Player:
signal health_changed(new_health: float)
И вызывать его внутри suffer_damage:
_ health_changed.emit(health)
А в редакторе сцен на вкладке сигналов инспектора Player соединить сигнал "health_chaged" с методом "animate_to" скрипта HealthBar. Тогда скрипт Player становится полностью независимым от HealthBar. Конечно, если ты переименуешь animate_to, тогда соединение отвалится, но игра не сломается (просто перестанет отображать актуальное здоровье игрока). Возможно, это нежелательно, т.е. лучше, чтобы игра падала с ошибкой "такого метода нет"... И вообще, по ООП ты не должен менять интерфейсы объектов... Просто показываю, что и как можно реализовать.
Ещё интересно: объявив suffer_damage ты можешь обращаться к нему извне, например, если у тебя есть лужица кислоты, которая посылает всем, кто в неё наступит, периодический урон. Для этого можно использовать утиную типизацию, например:
var suffer_damage: StringName = &"suffer_damage"
func _physics_process(_delta: float) -> void:
_ for body in get_overlapping_bodies():
_ _ if body.has_method(suffer_damage):
_ _ _ body.suffer_damage(damage_per_tick)
Тогда луже будет безразлично, что у тебя за игровые объекты - ей достаточно, чтобы у них был этот метод. Впрочем, возможно, так уровень гибкости тебе и не потребуется, но интересно знать возможности.
Ещё есть функция группировки, например, можно создать группу "damageable", чтобы возможно было временно исключить объект, у которого есть метод suffer_damage, из возможности получить урон:
var damageable: StringName = &"damageable"
func _physics_process(_delta: float) -> void:
_ for body in get_overlapping_bodies():
_ _ if body.is_in_group(damageable):
_ _ _ body.suffer_damage(damage_per_tick)
Впрочем, если у тебя в suffer_damage есть проверка возможности получить урон, такая группа не нужна.
И есть ещё куча вариантов как реализовать то же решение задачи. В программировании вообще очень много решений для любой задачи... Так что начинай с самого простого и дорабатывай по необходимости. Например, достаточно было менять value внутри HealthBar, потом пришлось добавлять новый скрипт и обращаться к новому методу, однако, если анимация не нужна, то не пришлось бы - так что добавлять этот скрипт и писать метод изначально не нужно. Сделай минимальную базу геймплея, а уже потом расширяй; переписать готовое по-другому обычно несложно.
Извини, если только запутал или где-то ошибся. В первую очередь обращайся к документации, только после её чтения прислушивайся к чужим советам (особенно это касается туториалов на ютубе).
>Почему не хочешь?
Вот как раз независимости компонентов и хочу добиться. Чтобы не было такого, что ради одного надо тащить целый ворох ненужного или перелопачивать половину структуры сцены/скрипта. Может просто не так выразился.
Спасибо за развёрнутый ответ, буду изучать.
>независимости компонентов и хочу добиться
Тоже хочу... Но на практике этого в любом случае сложно добиться, практически наверняка будут какие-то далеко идущие зависимости.
Лучше заранее планировать, в вики-формате или как интеллект-карту. Декомпозиция и всё такое. Поэтому абстрактный пример кнопки, спрайта и надписи не подходит, он слишком примитивен и абстрактен. В идеале нужно конкретный проект делать, пусть даже очень простой, а не просто изучать движок. Жаль, что туториалы часто учат только возможностям движка, но не планированию дизайна игры (геймдизайн).
Сигналы, методы и т.п. - практическая реализация абстрактных концепций, т.е. ты сначала должен определиться, что с чем у тебя в игре связано (из примера выше: HealthBar прикреплён к Player для отображения здоровья; к чему ещё он может быть прикреплён и для чего?), уже потом реализовывать средствами движка (ноды, сцены, сигналы и прочее).
Впрочем, слишком долгое планирование тоже может навредить: нужно проверять идеи на практике, иначе напридумываешь, а сделать не сможешь, или будет слишком сложно/скучно для целевого игрока.
>Я устал делать игры и хочу играть в игры.
А я устал играть в игры, поэтому хотел сделать свою.
Но потом я устал пытаться сделать игру.
Теперь я от всего устал...
>>973080
>Сделайте игру за меня
Тогда ты не получишь удовольствия создателя игры.
> Теперь я от всего устал...
Dat fil
личералли я последние 15 лет
дединсайд уже с пелёнок
https://matthewbarr.co.uk/bartle
Потом можно с нейронкой обсудить, что делать:
https://duckduckgo.com/aichat
Бесплатная книга о дизайне виртуальных миров:
https://archive.org/details/designing-virtual-worlds
Может, вернёте себе мотивацию игры делать?
мечтаю создать игру, интересную для самого себя
>Дизайн виртуальных миров 2003 года
Это год релиза Lineage 2. И за год до релиза WoW. Которые по сегодняшним меркам не очень актуальны. А сам автор задизайнил только текстовые МУДы в 1978. Что конечно похвально с точки зрения технического и концептуального, но скорее всего книга интересна только в историческом аспекте, как сейчас первые рогалики изучать.
Судя по документации, вес влияния кости на вершину (weight paint короче)
>Давно ведётся обсуждение того, чтобы сделать все аддоны независимыми от проектов
Можно запустить данный проект с одним только аддоном из командной строки. Получится почти стэндэлон прога.
>там гпт тупой
Я с Llama3 общаюсь, она няша-умняша.
>>973174
>не очень актуальны
Там суть совсем в другом:
>The aim of this book is to make people think about virtual world design. Whether you agree with any of it is not an issue, as long as you advance your own thoughts on the subject.
>...much of what you read in this book is doomed, eventually, to be proven wrong. However, it might well point the way to discovering what is right. All it takes is for people to think about what they’re designing; if reading this book helps in that respect, then it has done its job.
>I don’t care what you think, so long as you think.
На мой взгляд, фундаментально ничего за последние десятилетия не поменялось. Люди генетически не изменились => биологические функции активации остались прежними. Культура? Ну, мемы смешные. Игровые механики? Миров они не касаются. Мир не является сам по себе игрой, это что-то отдельное. В самом начале он жалуется, что дизайнеры слишком копипастят готовые миры - это поменялось? Нет, все современные игры - лютый конвейер копипасты... Поэтому мне кажется, что там что-то годное. Ибо о виртуальных мирах вообще мало кто думает в мире микротранзакций, лутбоксов, баттлпассов и прочего.
Я вот геймдевом увлёкся из-за ГТА. Но не из-за её механик, а из-за обширного мира, по которому я мог много часов подряд колесить без какой-либо цели. Заглядывать в случайные уголки, не отвлекаясь на какие-то там задания и игровые механики. Сейчас в большинстве игр такого спокойного изучения нет, обязательно есть напоминания о каких-то квестах, а мир вокруг тебя пустой, мёртвый и бессмысленный.
Ну, я поискал и там упоминается PvP и Permadeath, а это именно дизайн виртуальных миров, а не просто ворлдбилдинг.
Попробую разобрать все возможные подходы.
1. Визуальная лапша.
Довольно популярная тема благодаря встроенным GraphNode и GraphEdit. Сделать минимальный плагин с визуальной лапшой можно за пару часов вечером, поэтому многие пытались, и я в том числе. Сейчас не могу быстро найти аддоны, многие явно заброшены.
+ Визуально видно "ветки истории", циклы и т.д.
+ Можно легко перемещать ноды и группы нод.
+ Любой может сделать кастомный GraphNode.
+ Невозможно допустить "ошибку синтаксиса".
+ Похожее используют даже в АААА индустрии.
- Лапша быстро разрастается, трудно листать, поэтому придётся изобретать/использовать какие-то костыли.
- Часто такие редакторы сильно дробят всю лапшу на ноды. Пытаться избежать этого дробления сложно.
- Сложно поддерживать аддон/фреймворк, т.к. кроме основной работы нужно заботиться о "визуальности".
2. Кастомные меню.
Пример: Dialogic. Суть в создании кучи специальных менюшек под все случаи жизни: сюжет, персонажи...
+ Как и лапша, избавляет от синтаксических ошибок.
- Меню слишком линейные, плохо видно ветвление.
- Меню заточены строго под конкретную задачу.
- Зависимость от желаний чьей-то левой пятки, либо большой объём работ по поддержке разных меню.
- Требуют переключать фокус внимания (проблема с любыми редакторами со специфичной концепцией, отличающейся от основного инструмента, т.е. Godot).
3. Кастомный язык.
Пример: Rakugo, скрипты Ren'Py. Это язык сценариев, заточенный специально под диалоги, ветвление и т.д.
+ Можно писать в любом текстовом редакторе, хоть с кнопочным телефоном лежи и печатай свой шедевр.
+ Не слишком грузит движок чем-то избыточным.
+ Удобнее для писателей и программистов, т.к. ты работаешь с текстом в единственном окошке.
- Легко допустить синтаксические ошибки, при этом поддержки анализатора как в редакторе кода нет, соответственно нет и автодополнения кода.
- Очень сложно работать с ветвлением. Даже если разделять на отдельные файлы, путаница большая.
4. Код на GDScript.
Т.е. буквально ООП-велосипед, прямо на GDScript.
+ Нет сторонних зависимостей кроме Godot.
+ Нет оверхеда на парсинг сторонних скриптов.
+ Доступно автодополнение, типизация, дебаггер.
+ Можно сделать ctrl+клик, писать документацию.
+ При желании пиши хоть в простейшем редакторе.
- Много бойлерплейта по типу: godette.says("hi").
- Навигация не сильно проще кастомного языка.
- Чуть сложнее для писак, рисовак, дисигнеров...
5. Свои Resource.
Абстрагируемся от данных, делая потомки Resource, в полях которого вводим все диалоговые данные.
+ Нет сторонних зависимостей кроме Godot.
+ Доступна вся мощь редактора ресурсов Godot.
+ Что-то простенькое легко смастерить на коленке.
- Редактор ресурсов кривой и не слишком удобный визуально, особенно в случае вложенных ресурсов.
- Недостатков столько, что лень перечислять...
6. Свои Node.
Абстрагируемся от данных, делаем потомки Node и размещаем их в дереве сцен. Сцены можно потом комбинировать, создавая структуры уровнем выше.
+ Нет сторонних зависимостей кроме Godot.
+ Доступна вся мощь системы нод и сцен Godot.
+ Проще добавлять ресурсы в ноды, чем в ресурсы.
+ У нод порядок с иерархией => видно ветвление.
+ Можно добавить кастомные иконки нодам.
+ Легче менеджмент загрузки/выгрузки сцен игры.
+ Сцены есть сцены, а не абстрактный велосипед.
+ Удобнее и надёжнее супер-вложенных ресурсов.
+ The Godot Way™, если я правильно понимаю...
- Сцены сложно редактировать в Блокноте. Лол. Но можно написать транслятор из сценарного языка.
Более-менее глубоко пробовал подходы 1/3/5.
Не пробовал 2 - по скриншотам уже не хочу.
Аналог 4 пробовал на JavaScript, это БОЛЬ.
Теперь хочу погрузиться с головой в 6.
Знаю, что даже не оценивал сложность перевода на другие языки, подключения звуков, UI и т.д. Если инструмент/подход плохо работает в простейшем случае, то остальное просто нет смысла проверять.
Видел конечные автоматы на нодах и такой "да ну, выглядит дико, оно же будет каждый кадр бегать по списку", но в диалогах такой беготни 100% не будет.
Что ещё я не учитываю? Какие подводные?
>Что ещё я не учитываю?
Арт и свою способность написать интересный сценарий и диалоги.
>Так делай на ренпу, зачем тебе годотя
Чтобы был потанцевал для роста (2D => 3D).
К тому же, Godot я хорошо знаю, а Ren'Py нет.
>>973271
>Арт
Нейронка посоветовала рисовать в MS Paint...
>интересный сценарий и диалоги
Да это мелочь, моя задумка не требует сценарий.
> моя задумка не требует сценарий
>>973264
> Внезапно захотел сделать визуальную новеллу.
Ну справедливости ради некоторые концептуальные проекты не требуют большого проработанного сценария, а только лор, аллюзии на культуру и историю, философские измышления, обернутые в легкий ненавязчивый геймплей но сомневаюсь, что анон именно задумал и сможет реализовать
Проблема в том, что он называет новеллой то, что... а хотя... похуй.
Имлаинг перечисленное тобой сделать гораздо больше чем качественный сценарий.
Да у меня тоже не фокус. Узнал про одну настолку, подумал почему по ней до сих пор не сделали видеоигру, нашел что в 2003 взялись но фирма разорилась. Так что конкурентов у меня нет.
Пример преждевременной оптимизации, только в масштабах планирования проекта.
Делая вручную на if-else ты бы уже закончил игру за это время.
А правообладатель у этой настолки имеется? А то имей ввиду, тебя выебут и высушат в случае чего.
Имеется, и права на видеоигру он писал у него, а не у издателя настолки.
Поэтому тут железный план "Капкан".
Если ему понравится игра и он ее одобрит, то она будет официальной.
Если нет, или он не ответит, или права продал кому то другому - игра выходит под другим названием.
Игры не патентуются, игровые механики не патентуются, визуала и текстов там не будет общего, и вообще реалтайм шутер вместо пошаговой.
Журналисты пишут что это же как "игранейм из детства, только везде бах бабах" и делают бесплатную рекламу.
>называет новеллой
"Визуальной новеллой" у нас называют такое:
- фон на весь экран (опционально);
- персонаж(и) отдельно от фона (опционально);
- GUI блок снизу экрана с выводом текста;
- GUI кнопки с выбором ответа (опционально).
Всё остальное значения не имеет, включая сюжет. Формально сюжет может быть, но это не главное.
На Godot очень легко сделать визуальную новеллу: практически любой игровой интерфейс значительно сложнее базовой визуальной новеллы. Вот только генерация текста и выбор картинок - задача не столь простая, если ты хочешь вырваться из рассказов во что-то более близкое к играм. Там организационные вопросы сложнее придумывания общего сюжета. Смотрел, как это решают в ААА - очень уродливо.
>>973291
>только лор, аллюзии на культуру и историю, философские измышления
Хочу начать с диалога, а дальше посмотрим. Видел подобные игры, сюжета действительно нет, если не считать сюжетом разблокировку новых функций.
>>973303
>Делая вручную на if-else ты бы уже закончил
А я не хочу "заканчивать". Я хочу фундамент. Когда страничка с заголовком "улица" содержит десяток отдельных if-else в однородной каше, а выдаёт не больше двух предложений - это не фундамент, а виртуальное болото, где тонут все твои идеи.
Поэтому ищу способ организации, который не будет отягощать спустя N-ое число if-else и строк текста.
Короче, масштабируемость нужна.
Почему не масштабируется:
1. Лапша: слишком много ниточек и нод. Группы, отдельные вкладки тяжело поддерживать. Польза визуальной составляющей ниточек сомнительна.
2. Меню: линейность, тяжело поддерживать.
3. Сценарии: линейная портянка, запутаешься.
4. GDScript: бойлерплейт и линейные портянки.
5. Ресурсы: GUI плохо подходит для вложенности.
6. Ноды: смотря как реализовать... наверное...
>А я не хочу "заканчивать"
В этом и проблема. А ты захоти создать законченную игру, а не ковыряние в кишочках.
>Тяжело поддерживать
В визуальной новелле нечего поддерживать. А если и понадобится, это элементарно вернуться и за пять минут переделать вручную.
Не очень понятен твой вопрос.
Можно использовать эмодзи в тексте.
Можно использовать шрифты с иконками, вроде font awesome (но надо придумать как скомбинировать с обычным шрифтом)
Можно использовать текстурный атлас, чтобы показывать только регион текстуры - можно нарисовать все буквы на одну текстуру и скриптом автоматически нарезать.
Буква - это символ.
Иконка - это текстура.
Что тебе конкретно нужно сделать?
https://en.wikipedia.org/wiki/XY_problem
>захоти создать законченную игру
Делал "законченные" игры, мне это не интересно.
>вернуться и за пять минут переделать
Искусственный интеллект персонажей в сложной ролевой игре, симулирующей реальную жизнь, ты тоже за пять минут переделаешь с гарантией, что ничего не сломается? Если да - делись секретом, как организовывать всё, чтобы не было лапши, где одно минимальное изменение ведёт к катастрофическим поломкам в разных углах игрового мира.
В принципе да, только я бы:
1. добавлял не в корень, а в специальную ноду в иерархии специально для спецэффектов
2. постарался использовать пулы объектов, чтобы переиспользовать, а не пересоздавать каждый раз одни и те же сцены.
3. посмотрел в сторону партиклей
Да, с астероидов будут ресурсы падать, которые можно будет продавать, либо использовать в прокачке
Чтобы я сказал: вот символ допустим '#', сделай так, чтобы он был на месте иконки в айтем листе
Ну, атлас это самое простое что пришло в голову. Потому что легко автоматизируется. В годоте нет ноды чтобы рисовать в текстуру шрифтом. А атлас для фиксированной таблицы букв проще чем возня с вьюпортами.
Но возможно itemlist просто не для тебя. Он довольно слабый по фичам. Лучше делать полноценный гуй на HScroll и там хоть целую сцену туда с любым лэйаутом запихивать.
>чтобы он был на месте иконки
А разве по умолчанию в ItemList нужны иконки?
Если не ошибаюсь, если у тебя вообще нет ни одной иконки, то у тебя не будет отступа от левого края. Т.е. можешь просто список из текста сделать вот так:
# Первый
$ Второй
& Третий
Если тебе обязательно нужен "чистый текст", т.е. ты хочешь отделить "иконку" от "подписи", тогда можно просто отбрасывать первые две позиции в строке:
var symbol = "# Первый".left(1) # вернёт "#"
var label = "# Первый".right(-2) # вернёт "Первый"
Зачем игры, если можно болтать с чатботом?
Наверное он хочет большую букву, типа
#первый
>хочет большую букву
Тогда только специальный шрифт использовать.
Либо, как тут >>973354 - пилить свой велосипед.
Запись экрана бесплатно, без СМС и регистрации:
https://obsproject.com/
Разберётся даже мартышка твич-стример.
>как лучше сделать эффект "смерти" астероида
Просто нарисуй кусочки разлетающиеся. Сделай так, как удобнее будет поддерживать. Об оптимизации будешь беспокоиться, когда её станет не хватать.
>создать сцену для подобных эффектов, добавлять в нее нужную анимацию, и спавнить ее в корне, удаляя ее после проигрывания
У этого метода есть нюанс - кэш ресурсов:
1. При первом добавлении эффекта в сцену будут создаваться новые наборы ресурсов, типа текстур.
2. Когда из сцены удалены все экземпляры эффекта, связанные наборы ресурсов удаляются из памяти.
Поэтому лучше хранить один эффект в резерве, не добавляя его в сцену, но и не удаляя. Создаёшь его на первом уровне и не отпускаешь до конца игры. В таком случае все связанные ресурсы будут в кэше, ускоряя создание новых экземпляров сцен.
Заметил это в 3D прототипе с системой частиц: при добавлении сцены в дерево был ощутимый лаг, но я выяснил, что это из-за создания ресурса, который по моему недосмотру зря выгружался из памяти. После создания резервной копии лаг полностью пропал, несмотря на спам множеством новых копий.
>>973342
>добавлял не в корень, а в специальную ноду в иерархии специально для спецэффектов
Лучше в потомки астероида, что скажешь? Чтобы эффекты удалялись вместе с самим астероидом.
>постарался использовать пулы объектов
В Godot пулы обычно неэффективны. Лучше просто заранее создавать эффект для каждого астероида (поэтому размещать его внутри сцены-астероида), вместо организации общего "пула эффектов".
>посмотрел в сторону партиклей
Это само собой разумеется же.
>Чтобы эффекты удалялись вместе с самим астероидом.
Я обычно с этим на... обламывался, потому что была привычка делать queue_free. А так придется заводить астероиду какое то состояние послесмертия, следить чтобы он больше не обладал физикой, коллизиями и тд. Поэтому проще удалить астероид и создать абсолютно ни с чем не связанный объект эффекты.
>В Godot пулы обычно неэффективны
С чего ты взял?
>Это не спортивно
Решаешь проблему через ООП:
1. Создаёшь новый класс MyItemList.
2. Объявляешь красивый интерфейс (публичные свойства и методы, через которые управляешь):
- get_my_icon(id)
- get_my_label(id)
3. Твёрдыми руками берёшь совочек и веник.
4. Сметаешь все костыли в реализацию класса.
5. ???
6. У тебя восхитительная реализация. А все жуткие внутренности можно будет потом заменить. Или нет.
Настоящие спортсмены бы модифицировали исходники движка, чтобы он рисовал букву вместо иконки, или например использовал richtextlabel внутри itemlist, чтобы можно было давать разметку.
>Поэтому проще удалить астероид
А почему ты его удаляешь? Пусть сам:
1. Что-то наносит урон астероиду.
2. Астероид считает "ага, у меня 0 хп".
3. Астероид удаляет свою физику + графику.
4. Астероид запускает эффект "пук.wav".
5. Астероид ждёт окончание эффекта и удаляется.
Ничего извне делать с астероидом не нужно.
>абсолютно ни с чем не связанный объект
Иногда на экране остаются ФРАГМЕНТЫ ОКОН из-за какого-то бага в программе. Натурально, убиваешь процесс через диспетчер задач - а какая-то бяка на экране продолжает висеть. Почему? Потому что не связана ни с чем... Точнее, связана, но НЕ С ТЕМ. Я вынужден убивать explorer.exe, чтоб перезапустить рабочий стол из-за совершенно другой программы.
А теперь представь то же самое в игре. Только вот игрок не может убить одну ноду, только всю игру перезапустить. Что очень сильно раздражает...
>С чего ты взял?
Ладно, какая-то польза может быть, но не такая уж большая, чтобы обмазываться ими в самом начале простейшего проекта. В Unity советуют пулы кому попало из-за сборки мусора, ведь лишние объекты автоматически не уничтожаются, пока сборщик не проснётся по расписанию. В Godot лишние объекты уничтожаются сразу (queue_free - в конце текущего кадра), поэтому никакой головной боли не создают. Банальные Tween в ядре движка созданы чтоб тупо создаваться и сразу умирать, и их все обожают как идеальный инструмент анимаций - создал и забыл.
>3. Астероид удаляет свою физику + графику.
Я так вначале делал, когда был нюфаней. Это как раз многое запутывает, потому что ты удаляешь часть объекта. Потом придется разгребать баги, потому что где-то в коде ты ожидал что коллайдер есть всегда.
Только при удалении тебе потом придется создавать объект заново. А еще добавлять в дерево (если делать это в лоб, то там еще сравнения строк, поиск пути...)
Чет проиграл, поискал бенчмарк, чел пишет "никакой разницы". И показывает скрины где пулинг на 18% меньше фреймтайм.
>ожидал что коллайдер есть всегда
Нет коллайдера - нет проблем. Документация вроде рекомендует не трогать CollisionShape2D/3D, ибо это абстракция над физическим движком, чтобы юзер настраивал шейпы визуально в редакторе сцен.
Не хочешь удалять - можно переключить disabled.
В любом случае. Если у тебя заглючит компонент астероида, ты можешь увидеть, в каком он виде находится в сцене и сделать выводы. Если у тебя абстрактный "ничейный" эффект заглючил - поди попробуй найти его хозяина, которого уже нет. Не обязательно глюк эффекта из-за самого эффекта.
>>973449
>придется создавать объект заново
Движок это сам делает. На C++. А твой пулинг будет, скорее всего, на GDScript, в виде такой вот портянки:
func reset() -> void:
_ transform = Transform.IDENTITY
_ health = default_health
_ speed = Vector3.ZERO
_ state = State.IDLE
_ blablabla = Blablabla.new(default_data)
_ # CRITICAL TODO: что-то забыл... но что?
И эта портянка должна расти с ростом багофич.
А без пулинга ты ПРОСТО создаёшь и удаляешь, а всю сложную работу за тебя делает движок, без костылей.
>никакой разницы
>пулинг на 18% меньше фреймтайм.
Это на уровне погрешности. Ты потом больше будешь голову ломать, почему твой объект грязный, почему не хватает объектов, почему странные баги, которых вообще не может быть по логике твоих объектов...
И потом, надо смотреть по ситуации.
Одно дело - пулинг пулек пулемёта в булетхелле.
Другое - астероиды, которых 10 штук на экран.
>ты понижаешь суммарный IQ треда
Извини, что понизил твой IQ настолько, что у тебя теперь даже с базовой арифметикой проблемы.
добавил очков IQ в пул треда
Так лучше? Возьми побольше очков из общего пула. Понимаю, тяжело думать, когда все очки потрачены соседним постом, а создавать новые запрещено.
>>973461
>Будь дружелюбным
Не обижайся на него, такое бывает, когда пул IQ истощается и аноны отвечают только за счёт EQ.
>>973473 (OP)
>>973473 (OP)