Шапка: https://hipolink.me/godothread
Предыдущий: >>1048979 (OP)
Архивный: >>1040245 (OP)
Он и сам по себе работал через раз (раз в 10 попыток) в последние пару месяцев
зависимые от игрушек плебеи истерят отключением от примитивной Матрицы для зомби
Норм first-пика не было для 69?
Мне кажется или прошлый тред как-то быстро довели до лимита?
Если ты вкатун - то дополнительные аддоны только запутают тебя. Так что делай на чистом движке, система UI-нодов вполне мощна чтобы запилить имитацию телефонного чата.
>все
Дибилы блять. Как будто никто не умеет обходить блокировки
>Статичных или интерактивных?
Динамичных. Хочу эмиттер привязать к динамичному мешу. Но без коллизий и прочего. Нет интерактивности в этом смысле.
>Где-то далеко на фоне или вблизи?
Вблизи, поэтому визуал волнует
>Стилизованно или фотореалистично?
В стилизации
>1. Делаешь в Blender меш в форме водопада.
О, это интересно. Попробую еще с мешами поиграться, спасибо!
>Есть "визуальные" шейдеры - ИМХО, неудобные...
Неудобные они для сверхразумов. Сколько ни пытался вкатиться в написание шейдеров, все тщетно. Именно шейдерный язык не поддается. Мой потолок - качать готовые шейдеры и вырезать ненужное. Ну или с лапшой визуальной играться. Я дебил.
Хочу для прекола выходными в юнити ковыряться, но в удовольствие.
>привязать к динамичному мешу. Но без коллизий
Хочешь, чтобы поток спермы проходил сквозь тян?
>визуал волнует
>В стилизации
Тогда главное - попадать в стиль других ассетов.
>Попробую еще с мешами поиграться
Если к "динамичному мешу", то вряд ли подойдёт...
>Именно шейдерный язык не поддается
Конкретно что тебе там не поддаётся-то?
>тип_переменной имя_переменной = значение;
>ЦВЕТ = имя_переменной.операция() + значение;
Вот и весь шейдер. Или тебя английский смущает?
>или с лапшой визуальной играться
Эта лапша не избавляет от линейной алгебры...
>Конкретно что тебе там не поддаётся-то?
Да бля, там считать нужно. Косинусы, синусы, нормализовать под ЮВ развертку текстуры. Оч сложна. Я обосрался ещё на стадии прохождения офф. годотовского туториала
Другой анон
>Косинусы, синусы
Мне они пригодились только в двух случаях:
1. Преобразовать угол в точку (x, y) на окружности;
2. Добавить плавную "волнообразную" анимацию.
>нормализовать под ЮВ развертку текстуры
Что? Так сложно написать x = normalize(x)?
>Оч сложна. Я обосрался
Но на GDScript ты же можешь что-то сделать?
> Косинусы, синусы
> Оч сложна. Я обосрался
Вот тебе бумажка.
>Что? Так сложно написать x = normalize(x)?
Не, я там писал типо texture(noise, (position / 10.0) - offset).r
Как-то так.
>Но на GDScript ты же можешь что-то сделать?
Я свожу всю математеку к минимуму. Либо прошу посчитать нейросеть, либо, как в случае с косинусами - вывожу в экспорт Curves и настраиваю "как чувствую"
>Хочешь, чтобы
А ты как узнал? Ну вообще-то именно это мне и надо. Постеснялся говорить. Только не насквозь, если возможно. Я не уверен, можно ли сделать так, чтобы партиклы исчезали или скрывались при соприкосновении с другой мешкой. Я пробовал галочки тыкать в эмиттерах и направлять их в коллайдеры, но как-то не помогало.
>Конкретно что тебе там не поддаётся-то?
Да функции и переменные совсем незнакомые, плюс еще хорошо бы логику не переусложнять кучей условий, учитывая сколько таких операций в секунду крутится. Ну и синтаксис снежинка хрупче плюсов по ощущениям.
>Не, я там писал типо texture(noise, (position / 10.0) - offset).r
А, бля, я напиздюнькал. Просто скопипастил первое, что попалось. Давай сделаем вид, что я этого не писал.
>Чатгопоту возьми.
И будет у него очередная обёртка над LLM:
>Чтобы поиграть, купите API ключ у OpenAI...
>>1051768
>визуальную новеллу в виде чата в телефоне
Не понял, пользователь вручную набирает текст? Из личного опыта: LineEdit/TextEdit на Android странно перекрываются виртуальной клавиатурой и что-то непонятное происходит с сигналами. Так и не смог разобраться, как сделать окошко чата, чтобы оно автоматически подстраивалось под клавиатуру. Но, кажется, всё необходимое для этого уже есть в API.
Если просто кнопки нажимать, то это очень просто.
>Что готовое взять
Ну, не знаю, попробуй взять Godot 3.6.1, например...
>>1051778
>система UI-нодов вполне мощна
Для VN важнее всего формат записи истории...
>>1051809
>попробовал dialogic но понятнее не стало
Он нужен для записи/описания сценария.
Попробуй https://twinery.org/ вместо Godot или для прототипа, который потом можно экспортировать и пересобрать игру на Godot. Но вообще-то Godot для примитивных текстовых игр - это оверкилл... Если необходим именно Godot, пересобери без лишнего - сэкономишь несколько десятков мегабайт apk. Но производительность отрисовки текста тут будет однозначно хуже нативного рендеринга в ОС...
Godot имеет смысл для графических игр. Для GUI приложений (или их имитации) всё-таки не очень - приблизительно как приложения на Electron... Хотя, учитывая развитие веба, может, Electron не так плох.
>А ты как узнал?
С самого начала было такое подозрение:
>сделать густую струю жидкости в 3д
>Красивые однородные густые струи
Проблема в том, что у спермы очень неоднородная структура - там в составе как прозрачная текучая жидкость, выделяющаяся железами, так и белые сгустки сперматозоидов. Всё это имеет физически сложную модель поведения. Так что реалистично изобразить сперму в игре, тем более в 3D, трудно... Невероятно трудно. Обычная чистая вода не идёт ни в какое сравнение за счёт своей однородности. Большинство художников рисуют какую-то фигню нереалистичную даже на статичных 2D рисунках...
Так, может, не стоит слишком париться об этом? Нарисуй что-то абстрактно-белое и не парься. Все прекрасно понимают что это сложно нарисовать правильно, да и не нужно (кроме как для особых фетишистов на сперму, наверное, но таких мало).
>партиклы исчезали или скрывались
>направлять их в коллайдеры
Просто им нужны специальные коллайдеры:
https://docs.godotengine.org/en/stable/tutorials/3d/particles/collision.html
>функции и переменные совсем незнакомые
Читай документацию, там всё описано.
>логику не переусложнять кучей условий
Это как раз наименьшая из проблем...
>Просто им нужны специальные коллайдеры:
А, онана че... Тогда май бэд. Спасибо еще раз!
>очень неоднородная структура
>прозрачная текучая жидкость, выделяющаяся железами, так и белые сгустки
Хех, ну думаю, этим можно все же пренебречь. В аниме стиле за такое вряд ли осудят.
>Нарисуй что-то абстрактно-белое и не парься
Да, я так и пробую. С небольшой прозрачностью.
Спасибо за такой развернутый ответ.
Да вообще-то я делал на renpy новеллы, но надоело ебаться с интерактивом, казалось что годот проще позволит сделать переключение вкладочек и некоторые простые геймплейные элементы. А так да, игра просто визуальная новелка в телефоне.
Ещё один момент: ИРЛ спермы выделяется за раз максимум 5 мл - 1 чайная ложка; но главное, что скорость движения спермы может быть аж 13 м/с (получается 20 см за кадр на 60 FPS, 40 см на 30) и дальность полёта до нескольких метров. Т.е. чисто технически заметить "густую струю" в полёте будет проблематично. На видео в интернете чаще можно разглядеть только результат попадания - обычные видеокамеры, как и глаза человека, не способны запечатлеть её в полёте дольше чем на 1-2 кадра (в зависимости от расстояния, но оно чаще короткое).
Попадания в поверхности можно сделать декалями, которые также возможно научить "сплозать" (самое сложное - это определить направление движения):
https://docs.godotengine.org/en/stable/tutorials/3d/using_decals.html
https://docs.godotengine.org/en/stable/classes/class_decal.html
А для движения в полёте хватит спрайта струи. За подробностями - ищи дульную вспышку в шутерах: примерно та же реализация для выстрела спермы.
Думаю, "густую струю" рисовать нужно только если извергается несколько литров за раз - при том очень медленно, а тогда тут нужна полноценная симуляция жидкости, а не просто какой-то мелкий спецэффект. Но изначально ты сказал, что симуляция не нужна...
https://ru.wikipedia.org/wiki/Проблема_XY
>переключение вкладочек
О, да, это в Godot очень просто сделать.
Самое простое - TabContainer, он всё сам делает.
Если хочешь анимации - TabBar + велосипед.
Но и чисто велосипед сделать несложно.
>простые геймплейные элементы
Например, три-в-ряд? Тогда Godot будет норм...
>А в плане багов
На старых версиях у меня моргали контекстные окна, помоему в после четвертого пофиксили
Самое главное - бинарник Годота (если захочешь через консоль собирать или что) у тебя "закопан" будет внутри фаила-папки установленного приложения.
Плавный пиздатый маковский скроллинг на кончиках пальцев Годотовским редактором не поддерживается. Кнопки home end(если они у тебя будут)ведут себя не лучшим образом.
В МОГИЛУ
В МОГИЛУ
В МОГИЛУ
Сделойте игру, суть токова: >>834219 →
Джва года жду.
Корёжит бесноватого? Корёжит соколика, от любви и ласки корёжит?
> Попробуй twine вместо Godot или для прототипа, который потом можно экспортировать и пересобрать игру на Godot.
Я как-то пробовал. Мой внутренний программист нахуярил туда в пассажи логики, стейтов, параметров, и экспортер имеющийся ничего этого не видит, экспортирует только простой текст, которого в итоге оказалось очень мало - большая часть контента (который проходится 5 минут неторопливого чтения) оказалась под скобками длиннющих иф-элсов.
Обрацйы на пикрелейтедах. Суть на видеорилейтеде.
Оригинал в >>1002032 →
У червей натуральный сосалик в разлагающемся трупе. последние искры гаснут, надвигается эра тьмы, следи за кострами.
Это ж мисайд на максималках.
>Разные миры
А корованов пограбить не хочешь? В сущности сюжетка демонсоулс, живешь в могиле хабе, тепаешься в миры, и там воюешь, в итоге развязка всей игры в том же хабе где открывается выход из могилы еще один мир после наступления каких-то условий.
А документацию обновили или я должен все эти фишки сам как-то почувствовать?
Судя по опросу стенсил не нужен больше чем половине разрабов, поскольку они клепают 2д слоп, так что подождешь еще чуток.
Ну может просто новайсы не могут нихуя больше сделать без хорошей документации и гайдов. Вот и клепают примитивный слоп.
>3
По сути это опциональные аргументы, как в питоне? Пару тредов назад кто-то такое хотел.
> мисайд на максималках
Ваще не в тему. Ваще даже не близко. Я просто в ахуе, ты это щас серьёзно написал?
Эм, всё не так. Там в треде белым по тёмно-синему написано, что недавно релизнувшийся Cronos намного больше похож на идею в посте. Пост про альтернативные реальности. А мисайд это про виртуальные миры. Это совершенно разные жанры. Совершенно иная эстетика.
>альтернативные реальности
>виртуальные миры
Я один нихуя не вижу разницы с позиции разраба? Это чисто лорная причина по которой меняются декорации уровней, связь между которыми обеспечивает одна и та же логика.
> Я один нихуя не вижу разницы с позиции разраба?
Ах вот мы как заговорили? Оправдываем свою косность некоей "позицией разраба"? Ну-ну.
Игры лучше свои показывайте.
Да как же их делать-то? В движке куча синглтонов! Ужас просто. Майнлуп - синглтон. Физика - синглтон. Даже Инпут - синглтон! Просто кошмар, надо все синглтоны вычистить, тогда и поговорим.
Делаю кароч третий уровень, и там типа суть что ты гдет по горам шароёбишься, и кароч мне нужно показать лес внизу, а я хз как, пока что просто натянул на меш натянул текстуру с нормалью, и выглядит по итогу всё как болото. А как сделать норм сильно не запариваясь вообще хз. Думал может просто накопировать кучу спрайтов, но эт наверн компьютер сломает
Ну кстати у меня аналогичная проблема. Я тоже ХЗ как делать игры. Я себе придумываю в голове что вот где-то в горах шароёбится ГГ, а внизу в ущелье лесной массив и река извилистая. А как это реализовать, я ХЗ. В голове уже всё красиво в 120 ФПС летает.
Решение обычно примерно такое:
1. Делаете что угодно в Blender.
2. Рендерите это в спрайт.
3. Вставляете спрайт.
На большом удалении в жизни все объекты выглядят плоскими, поэтому никаких там карт нормалей и даже рендеринга с разных ракурсов не нужно, если геймплей происходит на ограниченной локации, откуда игрок не может/не должен выходить. Для наглядного примера - попробуйте вылететь камерой (с помощью читов или специального режима игры, позволяющего летать сквозь стены) за пределы игровой зоны в любой "коридорной" или "аренной" игре с большим и далёким, детальным задником - он будет состоять из одной или нескольких плоскостей, кроме некоторых примитивов на средней дистанции. В некоторых играх задний фон вообще не является реальным объектом - долететь невозможно.
А вот если нужно дать игроку возможность бесшовно и без артефактов приближаться к далёким объектам - тогда это совсем другая проблема, которую в общем случае просто невозможно решить, есть только куча костылей. В общем и целом схема та же, что и в случае статичного фона, только спрайт рендерится движком с нужного ракурса из реальных игровых моделей и при приближении игрока подменяется LOD-ами (вроде бы, спрайт тоже считается LOD-ом)... При этом несколько отдельных моделей могут объединяться в один фоновый спрайт, чтобы минимизировать перерисовку и прозрачные пиксели. Чтобы скрыть артефакты перехода, в игре могут добавлять туннели, арки, высокие объекты и т.д., где расставляют триггеры. Т.е. швы у такого большого мира в любом случае есть, но игрок их обычно не замечает, потому что их аккуратно заворачивают в дизайн карты.
Конечно, самым простым решением будет поднять минимальные системные требования игры, но это сужает целевую аудиторию, вызывает негодование игроков, не попавших в целевую аудиторию из-за требований игры, и в конечном итоге не решает проблему совсем, а только отодвигает её чуть дальше, потому что даже у самой мощной системы есть предел возможностей.
>>1052259
>В годоте - никак
Это неправда. Реализовать-то можно, но требуется изобретать велосипед или искать и пробовать аддоны. Насколько я знаю, в Unity и даже UE5 искоробочного решения для этой проблемы нет, нужно покупать аддоны. "Наниты" в UE предназначены для динамической геометрии в непосредственной близости от камеры. Модули ландшафта работают только с геометрией ландшафта, а не с реками, деревьями, камнями и прочими декорациями. Да, конечно, есть платные аддоны, но они стоят слишком дорого для нищих инди, а их техническая поддержка (долговечность/надёжность) сомнительна.
>Это неправда. Реализовать-то можно, но требуется изобретать велосипед или искать и пробовать аддоны.
Нужно не просто изобретать велосипед, анон. Изобрести велосипед это присрать свои лоды и спрайты на фон. Нужно изобретать блядь космический корабль из палок и фапчи. А с учетом того, что в игре помимо графена должен быть ещё и геймплей - это настолько дебильное и неблагодарное занятие, что можно считать, что это невозможно.
Есть окно, в него должен лупить солнечный свет, ортогональный. Сейчас снаружи просто поставлен источник света, но это приводит к тому что стыки стен и потолка так же освещаются.
А ортогональный свет разве с этим поможет? Больше похоже что у тебя классический light bleeding через стыки. Потыкай настройки света, контакты, bias или что там в четверке. Алсо в тройке помогало стены сделать толще.
Это работает, но тени начинают плавать над объектами. Для статичного окружения свет можно просто запеч, а вот тень персонажа начинает терять ноги.
Нет, стоп, не туда кручу.
Похоже теперь работает нормально. Я только обновил железо и пересел на Forward+ и с ним похоже тени работают нормально, в режиме совместимости тени становились какими-то сетчатыми.
Да, один таки взял на 512 под систему, а старый ссд на 200 использую для разработки.
У юнити и урины есть открытые багтрекеры?
Или там только "вы пробовали выключить и включить снова?"
В монолите (не модульном) синглтон это не антипатерн. Фига вас там в бэкенде надрессировали.
Да, да. Давай не будем это обсуждать и обвинять тех, кто обсуждает в движкосрачах, залетухах и что ты там ещё любишь писать.
Я не он, но все так и есть, ты палишься на раз-два, додикс примитивный.
Я понимаю, что ты шутишь, но всё-таки:
>Майнлуп - синглтон. Физика - синглтон.
Это не синглтоны - их можно заменить.
>Даже Инпут - синглтон!
Да, но вряд ли кому-то нужно его менять.
Синглтон - паразит, которого никак не удалить...
>>1052305
>В монолите (не модульном)
А это, по-твоему, что? Модули:
https://github.com/godotengine/godot/tree/master/modules
Инпут почему-то в другом месте:
https://github.com/godotengine/godot/tree/master/core
Подозреваю, что core значит "не трогать - опасно".
>это не антипатерн
Только если ты делаешь одноразовую лапшу...
> Это не синглтоны - их можно заменить.
Глупость какая. Если синглтон можно заменить, он от этого не перестаёт быть синглтоном. Давай определение синглтона в студию.
@
АРРЯЯЯ ЭТО СИНГОЛТОН
@
АРРЯЯЯ СИНГОЛТОН У МЕНЯ ПОД КРОВАТЬЮ
@
ИГРЫ ДЕЛАЙТЕ
@
КТО? МЫ?
Я не успокоюсь пока синглтоношизик не признает, что синглтоны нужны, синглтоны используются, сам Хуан закодил два десятка служебных синглтонов в движке. 90% аддонов представляют собой синглтоны, предоставляющие функционал аддона юзерам. Синглтоношизик неправ. И он это признает под гнётом пруфов.
А это вообще что?
https://github.com/godotengine/godot/issues/78513
Эта залупа как была с релиза годот 4 так никуда не делась.
А знаешь почему? Потому что всем похуй на шарпоцирк, добавленный ради грантов от майков. Нужно просто не юзать шарп. Хочешь оптимизировать код? Пиши на крестах.
Годочую.
Я вызываю функцию, она делает брррр. Профит. Вопроси?
>Если синглтон можно заменить
Когда ты что-то удаляешь, у тебя два исхода:
1. Проект не собирается, пока ты не удалишь 9000 упоминаний недавно удалённого элемента или не заменишь их чем-то подходящим по функционалу.
2. Проект собирается и работает без проблем, но определённая функциональность изменяется, либо отсутствует полностью, т.к. заменяется "заглушкой".
Синглтон - это одна глобальная сущность, к которой обращаются по имени, и без которой (или заранее определённых функций которой) проект ломается.
2D/3D физика в Godot не является синглтоном, т.к. используется паттерн dependency injection, который позволяет внедрить любую реализацию физики. Т.е. физический движок не завязывает всё на себя, а отвечает на запросы через интерфейс движка.
Другое дело, что ты не можешь переобуть Godot в процессе исполнения - физический движок может загрузиться только во время инициализации всего игрового движка. Поэтому нужно перезапускать редактор, если мы хотим сменить физику.
Аналогично выполнены многие другие модули, но некоторые присутствуют в одном экземпляре, т.к. альтернативных модулей пока что не придумали.
>>1052329
>закодил два десятка служебных синглтонов
И теперь разгребает это, переписывая с нуля.
Напомню, что Godot 4.0 сделали в основном ради переписывания графического движка на модульную архитектуру, позволяющую работать не только через OpenGL, но и Vulkan, Metal, DirectX и что угодно ещё. В предыдущей версии OpenGL был прибит гвоздями.
Алсо,
>синглтоны в движке
Это не то же самое, что синглтоны в твоей игре. Тут регулярно всплывают мнения "игра должна быть разработана на единственной версии движка и не переходить на новую ни при каких условиях", т.е. те "синглтоны в движке" никак не изменятся в игре.
Но когда ты делаешь игру, это непредсказуемый, практически хаотичный процесс, как и любая по-настоящему творческая деятельность. Можно реализовать что-то несколько раз за проект, долго перебирать варианты реализации, передвигать громадные блоки кода с места на место, банально экспериментировать с разными функциями игры. Определённых заранее решений практически нет, поэтому нельзя полагаться на паттерн "синглтон" - практически наверняка его придётся переделать.
Более того, если ты делаешь много игр, даже не обязательно в одном жанре - очень удобно будет поддерживать коллекцию универсальных частей, переносимых с проекта на проект. И вот когда эти запчасти полагаются на несколько "синглтонов", ты вынуждаешь себя тащить с собой их все сразу, вне зависимости от их полезности в новом проекте.
Поэтому старайтесь избегать синглтонов в играх.
>90% аддонов представляют собой синглтоны
Потому что 99.9999% аддонов делают скучающие школьники, ниасилившие делать игру, и поэтому ковыряющие свои велосипеды. Им наплевать на будущее твоего проекта. Обосрутся с аддоном и не подумают о тех, кто от этого аддона зависел. А ведь синглтоны - это как раз очень жёсткие зависимости.
По сути полагаться можно только на сам Godot.
>>1052344
>Я вызываю функцию
У кого вызываешь-то? Источник функции важен.
Нафиг ты сорцы движка принес.
Ты отличаешь сорцы движка от API движка?
API движка (по сути фреймворка), это целостная архитектура.
Единственный случай, когда синглтон надо заворачивать в DI, это система где нужно конфигом налету подменять сервисы (в каком-нибудь монструозном бэкенде на базе Спринга).Именно оттуда и пошел вой что синглтон антипатерн, когда надо подменить сервис - а он пришит гвоздями в коде, даже если он полиморфен.
Забавно то, что объект все еще (и чаще всего) остается синглтоном.
Просто пришли тупенькие из бэкенда, их надрессировали что нельзя, а почему, понимания нет.
> сам себе и директор и швейцар
Это другой паттерн, god object
>>1052349
> 2D/3D физика в Godot не является синглтоном, т.к. используется паттерн dependency injection, который позволяет внедрить любую реализацию физики. Т.е. физический движок не завязывает всё на себя, а отвечает на запросы через интерфейс движка.
Тем не менее это синглтон, доступный в единственном экземпляре по своему уникальному имени.
> И теперь разгребает это, переписывая с нуля.
Никто там ничего не разгребает. Синглтонов даже больше становится. Функционал времени, например, из синглтона OS вынесен в синглтон Time.
> делают скучающие школьники, ниасилившие делать игру
Обидели заечку. Заечка мстит на двачах.
> Поэтому старайтесь избегать синглтонов в играх.
Делал бы игры, советчик мамкин.
> непредсказуемый, практически хаотичный процесс, как и любая по-настоящему творческая деятельность
> передвигать громадные блоки кода с места на место, банально экспериментировать с разными функциями игры
> поэтому нельзя полагаться на паттерн "синглтон" - практически наверняка его придётся переделать
То что тебе пришлось, не значит, что придётся другим. Пример синглтона WeatherManager в предыдущем треде. Он прекрасно будет работать при любом перетаскивании громадных блоков, а так же позволит получать локальные инстансы своего класса для любых дополнительных задач.
> И вот когда эти запчасти полагаются на несколько "синглтонов", ты вынуждаешь себя тащить с собой их все сразу, вне зависимости от их полезности в новом проекте.
Вот мы и дошли до главного соломенного чучела. Вот она подмена понятий. Чел не умеет проектировать, и нашёл себе виноватых. Использование синглтона не подразумевает связность кода. Связность кода нарастает сама про себе безо всяких синглтонов. Если человек не умеет, то и без синглтонов наворотит лапши, завязанной друг на друга сигнал-апами и колл-даунами.
Так что нет, не убедил. Синглтоны - наша тема. И шинами сигналов пользуйтесь посаны, не слушайте этого.
>Более того, если ты делаешь много игр, даже не обязательно в одном жанре - очень удобно будет поддерживать коллекцию универсальных частей, переносимых с проекта на проект.
Чтобы было что поддерживать надо сначала сделать, а я не могу не заметить что в твоем посте сплошное "будет".
Да на самом деле и просто сделать недостаточно - ноль смысла поддерживать игру с отсутствующей аудиторией.
Чтобы поддерживать что-то ненужное, надо сначала разработать что-то ненужное. А у нас игор нет!
Всегда можно разработать очко. А туда уже синглтон, и наслаждаться антипаттерном.
Ты просто игр не делал, поэтому не шаришь в теме.
Удачи поддерживать убийцу GTA, в которой Player - синглтон, а остальные системы обращаются к нему строго по имени, подразумевая его характеристики. Синглтон Weather тоже станет тебе обузой, когда ты захочешь сделать камеры слежения или телевизор.
>Удачи поддерживать убийцу GTA
Если ты в соло занимаешься убийцей GTA, то у тебя проблемы гораздо масштабнее чем какие-то синглтоны погоды.
Очередное соломенное чучело выкатил, напридумывал себе - и блестяще победил.
Прости меня Христа ради если чем тебя обидел или оскорбил.
Свою убийцу ГТА можешь не показывать, ведь она уже убила ГТА, и все о ней знают.
>Удачи поддерживать
Так ты нам альтернативу давай. Ты громко пукаешь, но молча нюхаешь.
Игру свою показывай, чучеловод.
>>1052411
Прощаю. А теперь показывай игру.
>>1052415
>ведь она уже убила ГТА
Это мем такой. Учи мемы.
>>1052419
>Так ты нам альтернативу давай
Альтернативу лапше из говнокода?
Показывай проблему, обсудим...
> Игру свою показывай, чучеловод.
> А теперь показывай игру.
Сначала ты свою покажи. Поиграем по мужски.
помогите дураку, не могу правильно отзеркалить оружие, чтобы помимо прочего оно правильно управлялось кнопками
Покажи скриншот/мокап скриншота своей игры.
Хотя бы в Paint мышкой накидай, чего ты хочешь.
> Советов не прошу.
Советую все переделать, а то тренарные выражения это антипаттерн.
Это игра а-ля червяки классические, я хочу чтобы при использовании кнопок оружие наводилось вверх/вниз, собственно я это уже реализовал для "обычного" поведения (когда перс смотрит вправо) хочу сделать то же самое когда он смотрит влево
>Альтернативу лапше из говнокода?
Как синглтон приводит к лапше? И почему ты путаешь синглтон с "God object"?
Ты не маневрируй, давай альтернативу, раз вякнул.
>>1052454
Не, падажжи, у тебя какая-то ерунда. Ты целишься мышкой же? Мышка тебе уже даёт точку на виртуальном круге, относительно которой ты должен посчитать угол и, если, по пикче >>1051815, у тебя 2 или 3 сектор, то у тебя моделька флипается. Флип модельки должен быть второстепенен. А судя по коду ты сначала флипаешь модельку, а потом из её флипа пытаешься логику развивать.
> правильно управлялось кнопками
Аа.. Кнопками. Значит, смотри. Домножаешь на -1 там где у тебя кнопи вверх-вниз. И всё. Я в третий раз смотрю на твой код и понять не могу. Нахуй так всё замороченно? Это нейронка насрала?
>Как синглтон приводит к лапше?
Очень просто: синглтон - это ГЛОБАЛЬНАЯ штука, а "глобальность" знаешь что означает на практике? "Глобальность" - это как выставить голую жопу на заполненной торговой площади и принимать всех, совершенно без ограничений. Найдёшь отца потом? Конечно же нет, через твою жопу 1000+ тел прошло.
"Локальность" - это семейные отношения, когда все знакомы друг с другом и делают всё по согласию, соответственно, в случае чего разобраться легко. Отношения внешние - с другими семьями - тоже зарегулированы и тоже легко отслеживаются. Нет беспорядочных половых связей - нет и проблем.
"Лапша" = "беспорядочные (половые) связи".
Синглтон - это только одна из причин лапши.
>И почему ты путаешь синглтон с "God object"?
Я-то не путаю. Но я понимаю, почему их так легко перепутать: т.к. синглтоны сидят в глобальном поле видимости, фактически они - один комок функций, и разделять их на отдельные классы не обязательно - создаются-то и уничтожаются они одновременно. Соответственно ньюфаг будет склонен собирать в единственном синглтоне всё, что ему понадобится. Например, та же "шина событий" - такой вот клубок, собирающий в себя никак не связанные сигналы.
А всё потому, что когда ты начинаешь вести эту беспорядочную половую жизнь, потом тебя кто-то уговаривает попробовать наркотики, а затем тебя любопытство разбирает попробовать потяжелее, и оказываешься в канаве, упоротый, без памяти, без документов, как кусок мяса в форме человека.
Твоя цель - повеселиться и побыстрее сдохнуть?
Или поддерживать благополучие своей системы?
Для себя решай сам, но новичков не втягивай...
>>1052463
Значит, начать надо с того, что использовать не flip_h, а transform.scale.x +/-1 и выстроить нодами привязки оружия к персу. Пикрелейтеды 1 и 2. Красный глаз у годобота чтобы видеть отражение по оси икс.
Нода Rot выделена на третьем скрине. Она нужна для поворота пушки относительно "руки перса", мысленной. Можно конечно и высчитывать это всё, но зачем, если можно просто ноду-ручку приделать?
Годочую, тоже это хотел ему посоветовать.
>Нода Rot
Рекомендую назвать "Pivot" - "точка вращения".
>но зачем, если можно просто ноду
В теории, у нод много лишнего (данных, кода).
В документации советуют нодами не срать...
И в третьих, получилось даже ничего умножать не надо. Всё автоматически разворачивается.
>>1052437
Вот, держи. Код на основе искаробочного 2Д-контроллера.
Я думаю, зависит от конкретной игры...
>Наводиться вблизи неудобно
Делай как в Genshin Impact - без наведения.
Вместо рейкаста там Area3D и меню выбора.
Откуда у тебя модели? Сам делал или скачал?
> У неё орбита как-то смещается, или что?
Да.
Нужно сначала пофапать, чтобы голова начала работать, а потом сесть и внимательно подумать, как именно должна располагаться камера? вокруг какой точки и по каким осям нужно вращать и двигать камеру, чтобы получить желаемый результат? Можно еще и схему нарисовать. А потом на нодах воспроизвести.
>Делай как в Genshin Impact - без наведения.
>Вместо рейкаста там Area3D и меню выбора.
Мне так не понравилось. У меня в игре разные взаимодействия есть, в том числе достаточно точные, и ареа слишком громоздкая для такого. Думал ещё комбинировать, но это уже какая-то гейм дизайнерская шизофазия получится, мне кажется.
Возможно я ориджин вращения камеры выставил не так, я хуй знает где он должен быть. Я выставил прямо в хребтину, чуть ниже шеи.
>Откуда у тебя модели? Сам делал или скачал?
Тело со смутбазы скачал, так как оно с блендшейпами а я заебываться не хочу. А вообще я сам делаю. Может, когда-то и своё тело доделаю, лет через 20.
>выставил прямо в хребтину, чуть ниже шеи.
Я тоже примерно так расположил камеру...
В общем, я сам толком не разобрался, как лучше это организовать, но думаю, что проблема с прицелом заключается в том, что когда ты пытаешься вниз посмотреть, камера поднимается вверх, отдаляясь от возможных целей, и поэтому тебе неудобно.
Возможно, лучше сузить FOV, когда камера сбоку? Уменьшенный FOV создаёт ощущение приближения несмотря на физическое расстояние до камеры. Т.е. прицеливаться в предметы на полу будет проще.
> Я выставил прямо в хребтину, чуть ниже шеи.
В общем и целом как-то так должно быть как на пикрелейтеде. За счет сдвига по армам и вращения по ротам, достигается любая нужная тебе степень свободы. Хоть пизду свою в зеркальце разглядывай.
Что-то ты перемудрил, лол. Официальный туториал:
https://docs.godotengine.org/en/stable/tutorials/3d/spring_arm.html
Вот тебе доработанный код с комментами.
Там на новый SDL перешли, теперь практически любые обскурные геймпады на любых платформах распознаются норм.
>жооорааа
Сук, это ж я.
>>Как синглтон приводит к лапше?
>Высрал графоманию вместо технического объяснения.
С тобой все понятно, хватит щитпостить в тематике.
Глобальный сервис это корневой (root) элемент системы. Отношение родительского к дочернему элементу это не нарушает (если сам говнокодить не начнешь и не начнешь совать потомков в корневые элементы или подключать связи с ними).
Вместо того чтобы идти получать новые знания, ты сидишь и самоутверждаешься через флуд, компенсируя незнания - графоманией.
Покормлю последний раз:
Еще раз отличие контейнера и синглтона - первый создан чтобы контролировать число объектов (сервис по хранению объектов), второй сам контролирует свои объекты (в какой-то степени он может быть даже фабрикой). И единственное когда это плохо, когда нужно сервисы менять "налету" (или распараллелить). Еще плюс контейнеров, это что они стимулируют писать в IoC, но в реале все это просто идет корнями от юнит тестов и вопросу о чистых функциях (в данном случае чистых объектов, о чем высрали целый отдельный принцип - инверсии управления).
Больше различий нет, а значит отличие хорошего подхода от плохого нет (я даже делал DI который дергался через Сlass.getInstance() и устанавливался через Сlass.setInstance(), чтобы в тупых языках/IDE сохранить автокомплит, это плохо, но это работало, потому что ничего не меняет).
Камера должна вращаться вокруг сосков, это старых известный хак в играх.
Такие дела.
Бля, там просто хуйня про то, как работает их документация. Типа вы там давайте, пишите, хорошего настроения.
>>1052585
Это документации на тему как, в целом, контрибьютить в движок. Там про все - от написания кода в движок до перевода и оформления документации. Поэтому оно на отдельном сабдомене. И это очень важно и полезно.
>давайте, пишите
Прикинь да, опенсорс, крауд фандинг, крауд сорсинг, все дела.
Прикинул и понял, что Годотя так и останется потешной поделкой в ожидании пока кто-нибудь, кому делать нехуй больше, сделает нормальную документацию.
Скажи честно, как часто тебе ПРИХОДИТСЯ делать что-то такое?
>ГлобальнаяСущность.какое_то_свойство = значение
>ГлобальнаяСущность.какое_то_действие(значение)
И главное: ПОЧЕМУ тебе ПРИХОДИТСЯ это делать именно так?
Задумайся. Прислушайся к своим ощущениям. Почему ты так делаешь?
Скорее всего, твой ответ будет примерно таким:
>Мне так удобно. Это быстро приводит к решению текущей задачи.
Но ты никогда не задумывался, какой ценой даётся это решение?
Если посмотреть в прошлое программирования, можно вспомнить, как раньше код набивали на перфокартах... Кхе, ладно, сейчас мы так не делаем. Потом научили компьютеры принимать код прямо с клавиатуры, и начали появляться первые языки программирования, какими мы их сегодня знаем. Ассемблер был первым - в нём ты набираешь команды, передающиеся напрямую процессору, в простейшем случае без какой-либо обработки (макросы и т.п. придумали значительно позже). Как организовать ветвление и циклы на ассемблере? Передать процессору операцию прыжка с условием, которое переводит указатель в коде на заданный адрес, если условие верно или не верно. А есть ещё операция прыжка без условия, чтобы можно было выполнить код в другом месте. Обычно код в другом месте выполняется и возвращает нас обратно, но не обязательно - так возникла команда "GOTO".
В большинстве современных языков программирования нет команды GOTO/JUMP, а если и есть, то о ней никто больше не вспоминает - но относительно недавно часто всплывали обсуждения, почему нельзя использовать эту команду в коде, даже если воспользоваться ею для решения текущей задачи намного проще альтернатив. Программисты буквально испытывали соблазн вставить парочку GOTO для удобства решения задачи. Почему GOTO настолько плоха, что её пришлось удалять из языков как запретный плод, искушающий программистов?
Вернёмся к ассемблеру: почему его практически не используют в его изначальной форме? Потому что читать, понимать и изменять код на ассемблере очень сложно. Почему сложно? Потому что ассемблер в чистом виде (без макросов) имеет только инструкции процессора, положение которых в памяти имеет значение, и переходы по которым могут быть запутанными для человека - всё из-за этих операций перехода, условного и безусловного. Ты смотришь в участок кода и не можешь понять, как он сработает, потому что процессор в него неизвестно откуда придёт и неизвестно куда уйдёт, т.е. ты не знаешь состояние памяти, регистров и т.п. в момент выполнения инструкций в этом участке кода. Для понимания придётся "раскрутить" весь код и проиграть его в голове или выполнить по шагам в дебаггере. Всё это долго и трудно - поэтому придумали другие языки программирования.
Первым делом новые языки программирования ввели структуры в коде - условные операторы, циклы, процедуры и функции, потом появились модули и, наконец, объекты (классы ещё позже придумали). Смысл этих структур в коде - организовать порядок выполнения чётким, наглядным способом. Т.е. вместо хаотичных прыжков по адресам в памяти код выполняется по определённым правилам. Злополучная операция GOTO позволяет вырваться из ограничивающих правил, сломав структуры, например, выпрыгнуть из "матрёшки" десятка циклов в совершенно произвольном направлении - другими словами, сделать то, что в ассемблере делается по умолчанию в любой программе. И если организация кода условиями, циклами и функциями делает код более понятным, операция GOTO, соответственно, снижает понятность кода для программиста (компьютеру на это всё плевать).
Но на одних процедурах и функциях делать сложные программы трудно, особенно когда тебе нужно много вспомогательных процедур и функций, много вспомогательных данных и т.п., и ты не хочешь позволять другим программистам трогать эти вспомогательные штуки без особой необходимости. Модули позволяют разложить процедуры и функции с данными по отдельным файлам и ограничить видимость снаружи, но модули нельзя клонировать в памяти. На помощь приходит динамическое выделение памяти под данные, но с динамическим выделением происходит та же самая ситуация, что и с операцией GOTO: у тебя есть кучка указателей в поле видимости и ты должен ими аккуратно управлять, чтобы не запутаться в том, что, когда и где выделяется и освобождается.
Решением этой проблемы стали "объекты" (но пока не классы). Объект - это комбинация кода и структуры данных, которую можно размножить в памяти сколько нужно раз, изменить и удалить по желанию в процессе работы программы, что качественно отличает их от модулей. Позже придумали классы, которые можно организовывать в иерархию, комбинировать и всё такое, но это всё не важно.
Изобретение объектов породило объектно-ориентированное программирование, которое задаёт ещё больше правил для работы с кодом, которые, по идее, должны ещё больше улучшать понимание кода программистами, даже если они этот код сами не писали. Ты не обязан соблюдать все правила, но несоблюдение правил ведёт к тем же последствиям, что и бездумное использование GOTO в коде: например, если ты залез в приватные свойства объекта и что-то изменил, его поведение может неожиданно измениться, а это повлечёт к изменениям в других объектах.
Если упрощать, в правилах ООП нет ничего особенного: просто не твори херню, которую ты мог бы с лёгкостью натворить в чисто процедурном языке программирования. Если объекту нужен какой-то другой объект, этот объект должен явно запрашиваться или явно создаваться. И чем меньше твой объект запрашивает что-то извне, тем лучше. Т.е. лучше, чтобы объект создавал свои объекты, пользовался ими и удалял их самостоятельно, никому не отдавая, чтобы избежать путаницы. Да, это может приводить к лишнему выделению памяти, но зато это упрощает понимание кода - ради чего языки программирования и изобретаются в основном (иначе до сих пор писали бы на ассемблере).
Наконец, рассмотрим "синглтоны". Что такое "синглтон"? Это уникальный и глобально доступный объект, создающийся в самом начале программы и удаляющийся перед завершением программы. В сущности, это ООП-костыль, возвращающий нас во времена, когда никаких объектов не было и все данные в памяти были доступны из любого участка кода, а все функции вызывались из любой другой функции. Если посмотреть ещё глубже в историю - это аналог беспорядочного GOTO/JUMP в коде программы, т.к. позволяет напихать спонтанных переходов неизвестно откуда неизвестно куда. Это буквально сознательный отказ от всех правил ООП ради "удобства" решения задачи: вместо создания вспомогательных объектов, запроса объектов извне, аккуратного управления объектами, ты просто втыкаешь глобально доступный рычаг, за который можно дёргать откуда угодно и когда угодно.
Что ж, всё ещё не видишь проблемы синглтона? Тогда ты не видишь проблемы GOTO/JUMP. Может, попробуешь сделать игру на ассемблере? Только что-нибудь посложнее давай, крестики-нолики любой дурак сделать сможет даже на ассемблере. Или скажешь, что это слишком сложно? А почему тебе так сложно писать на ассемблере без всех удобств высокоуровневых ООП языков? Может быть, потому что "неудобные" правила ООП придуманы, на самом деле, для удобства? И отказываясь от этих правил ты деградируешь до времён хаотичных прыжков по памяти и по инструкциям.
Я понимаю, лень сложно признать. Мы генетически захардкожены экономить энергию - и наш древний мозг не может понять, зачем ему тратить энергию прямо сейчас, если он может её сэкономить. Наш древний мозг говорит нам: если вот здесь воткнуть GOTO, мы быстрее решим задачу; если вот здесь обратиться к глобальной переменной, мы быстрее решим задачу; если воткнуть вот этот глобальный рычаг управления, мы быстрее решим задачу. Проблема в том, что наш древний мозг не способен смотреть далеко в будущее, он думает только о краткосрочных преимуществах. Древний мозг не разбирается в разработке программ и не может даже представить себе, какого это - заниматься одним проектом много месяцев и даже лет. Но ты-то выше него, у тебя новая кора есть, и она способна смотреть в будущее и оценивать последствия своих поступков.
Вот смотри в будущее почаще. И не допускай костылей в своём коде, которые потом усложнят тебе жизнь. А они тебе обязательно усложнят жизнь, если ты делаешь реально сложные игры. Делаешь ведь?
> Скажи честно, как часто тебе ПРИХОДИТСЯ делать что-то такое?
> get_tree().quit()
Частенько. Каждый раз, когда надо выйти.
> И главное: ПОЧЕМУ тебе ПРИХОДИТСЯ это делать именно так?
Потому что движок так спроектирован. Дальше не читал. Переделывай.
Идите вы, короче, нахуй, дебилы ёбанные
>Шизик срет аналогиями
За свою жизнь заметил такую тенденцию - если кто-то пытается что-то доказать с помощью аналогии, то у него просто нет нормальных доказательств.
Я тот кто тебя кормил и я не читал эту портянку. Знай это.
>Но ты никогда не задумывался, какой ценой даётся это решение?
Ваще похую чел
>В большинстве современных хуевых языков программирования для долбоебов нет команды GOTO/JUMP, а если и есть, то о ней никто больше не вспоминает - но относительно недавно часто всплывали обсуждения, почему нельзя использовать эту команду в коде, даже если воспользоваться ею для решения текущей задачи намного проще альтернатив. Программисты буквально испытывали соблазн вставить парочку GOTO для удобства решения задачи. Почему GOTO настолько плоха, что её пришлось удалять из языков как запретный плод, искушающий программистов?
Потому что припизженые каргокультисты, как и ты. Обмазываются своими выдуманными бест практис и ебут друг друга в жопы (неиронично).
>ООП-костыль
Сам по себе ооп тоже костыль, можешь послушать мнение функциональщиков.
>Это буквально сознательный отказ от всех правил ООП ради "удобства" решения задачи
Минусы будут? Если тебе не нужен мультиплеер - в инди геймдеве нужно делать как можно быстрее, не задумываясь. Если ты не спец - хуярь синглтоны. Если спец - хуярь безболезненно отключаемые синглтоны вперемешку с геймплеем в контентейнерах (я например имею ecs геймплей который на клиентской части цепляется к ui синглтону) и наступит праздник во всем мире и изобилие игр. А бэкендщики пусть дрочат паттерны, это их положняк.
А вы игры делайте.
Смотря что тебе удобнее иметь сверху. Если ты планируешь из общей сцены менять картинку спрайту - лепи сверху спрайт. Если нужны доступные опции area2d - лепи сверху ее. Когда не нужно ни то, ни другое, я просто node2d как топ контейнер делаю чтобы не путаться.
У меня почему-то такое ощущение что спрайт это типо как опция, сам объект это ареа, а ему уже опций накидываешь. У меня просто по клику спрайт становится активным, и удобнее вроде как когда он дочерний, всякие сигналы посылать по клику и тд
С одной стороны одинаково, с другой - чем "выше" нода, тем быстрее считается её глобальная трансформация. Но она считается и для отрисовки. Хз, делай как тебе удобнее.
Ща, падажжи. Мы мемы создаём, по которым нас следующие 10 лет узнавать будут.
Как тебе удобнее - так и делай. Я колижены кладу сверху, чтобы их в редакторе было видно поверх спрайтов.
>Частенько. Каждый раз, когда надо выйти.
Ручками эту команду набираешь в консоли?
>get_tree().quit()
Во-первых, это не синглтон, а обращение к самому себе (self).
Во-вторых, эта строчка в единственном месте всего проекта.
В-третьих, это API движка, а не твой личный код в проекте.
>Потому что движок так спроектирован.
Движок заставляет тебя создавать как можно больше лапши?
>>1052633
>решил проверить, как оно будет
Как будет что? Нормальный код без лишней лапши?
>>1052643
Если ты игр не делаешь - действительно без разницы.
>>1052635 >>1052636
>ad hominem
Загуглите, что это, чтобы реже быть баттхёртами.
>>1052645
>припизженые каргокультисты
Ты тоже "ad hominem" загугли - должно помочь.
>послушать мнение функциональщиков
Функциональные языки - это не для нас, а для математиков.
>Минусы будут?
Будут - в будущем, поэтому я и предлагаю избегать их заранее.
>в инди геймдеве нужно делать как можно быстрее, не задумываясь
Вот и я о том же. Нужно делать быстрее. А синглтоны создают пикрил ситуацию в любом проекте, что делается не за один вечер, даже если ты в одиночку всё делаешь. Сидишь, делаешь игру, пытаешься добавить фичу - нет, нельзя, нужно перерабатывать всё, чтобы эта фича встала на положенное ей место. Дёргаешь за один синглтон и весь проект разваливается, полностью, т.е. даже не удастся запустить, не то, что поиграть в него.
Потом будешь несколько дней/недель рефакторить, чтобы избавиться от этого неудачного синглтона, но только если ты разберёшься в запутанной лапше, которую ты совсем недавно радостно навешивал на проект. А рефакторить всегда неприятно, потому что прогресс не ощущается в сравнении с добавлением новых фич и фиксом багов, да и похвастаться не о чём. Если бы синглтона изначально не было, достаточно было бы перекинуть пару вызовов или ссылок в одном месте и всё, а с синглтоном нужно почти весь проект переделывать ради одного минимального изменения. Проще с нуля всё сделать, чем бороться с въевшимся в проект синглтоном.
Вы пока что не понимаете этого просто потому что у вас слишком простые, тривиальные проекты, какие-то клоны полностью готовых игр, где всё уже давно за вас решено и не нужно ничего придумывать. Или вы используете уже готовый фреймворк и просто добавляете свои картинки и надписи, делая чисто сюжетную игру без геймплея. Если б попытались сделать достаточно сложный проект, тогда бы поняли, что на синглтонах далеко не уедешь и нужно делать всю архитектуру как можно более гибкой, подвижной. Godot фундаментально располагает именно к гибкой, подвижной архитектуре игры, если не считать некоторых неудачных решений - тех же "autoload" синглтонов, методов для "смены сцены" в дереве сцен и т.п., что только зря путает новичков.
Вот как новичок изучает движок?
1. Узнаёт про ноды и сцены, учится писать код и т.д.
2. Создаёт игровую локацию и минимальный геймплей.
3. Хочет сменить локацию или открыть/закрыть меню.
4. Находит в API дерева сцены функции "change scene"...
5. ...и обнаруживает, что движок теряет все его данные....
6. Находит решение - поместить эти данные в "autoload".
7. Радуется, что персонаж переходит из локации в локацию.
8. Начинает использовать "autoload" к месту и не к месту...
9. Привыкает к ним, и замахивается на проект побольше...
Результат немного предсказуем, вы так не думаете?
При этом нет ничего, что нельзя было решить без "autoload". Это буквально фича без задач, если ты не используешь "change scene" в дереве сцены, а он тебе вообще не нужен, когда у тебя есть load(), add_child() и queue_free(), что дают тебе намного больше контроля, чем методы "change scene". Не говоря уж о том, что для бесшовного мира ты вообще не можешь использовать "change scene" и будешь добавлять новые куски мира через add_child(), а значит, не остаётся ни одной разумной причины использовать "autoload" в проекте, за исключением какого-нибудь счётчика кадров, который ты хочешь выводить при нажатии на F6 в совершенно любой сцене, но это опять-таки не синглтон (счётчику кадров не нужно быть глобально доступным, а глобальный доступ - важное условие синглтона). Но вот нюанс: если ты слишком сильно обмазался синглтонами (читай: глобальным доступом к уникальным объектам), F6 у тебя рано или поздно сломается (т.к. запутаешься в том, что твои синглтоны должны делать при запуске), не говоря уж о более долгой загрузке проекта при каждом рестарте (окно движка фризится, пока все начальные ноды не загрузятся и не инициализируются).
>имею ecs геймплей
ECS для геймплея не нужен, его роль - оптимизации кэша процессора, которые в геймплее работать всё равно не будут, если у тебя хоть сколько-нибудь сложная игра с нормальным количеством механик и вариаций объектов.
Впрочем, из-за ECS у тебя вряд ли сложный геймплей.
>>1052667
>Он игры не делает, он движок изучает
Я всё что нужно изучил и по граблям прошёлся - пытаюсь предостеречь других.
>Находит решение - поместить эти данные в "autoload".
В/из меню делаю change scene. Загрузка/сохранение данных через autoload скрипт, отвечающий за сохранения и загрузку (на самом деле для удобства два - один собирает данные, другой сохраняет/загружает)
Уже в самом геймплее при смене уровня
>load(), add_child() и queue_free(),
В чем не прав?
А как корректно и отказоустойчиво сделать систему сохранений?
У меня есть два autoload. Первый отвечает за сам процесс записи данных в файл сохранения и загрузку из него. Второй собирает данные из разных нод во временное хранилище, например, чтобы сохранить прогресс при перехода с одного уровня на другой уровень и обратно, или чтобы сбросить прогресс, если игрок помер.
Ячейка (сиреч файл) сохранения у меня один.
Последовательность такая:
1) Есть уровень: враги, объекты в разных состояниях и позициях, предметы и т.п.
2) В течение геймплея никаких сохранений не порисходит
3) Если игрок делает ключевое действие (например, сохраняется), то запускается процесс сохранения
4) Скрипт 2 (сборщик данных) дергает все на уровне все, что может сохраниться и записывает это к себе
5) Потом Скрипт 1 (save/load) обращается к скрипту 2, берет оттуда данные и несет их в файл сохранения
6) При загрузке игры берем данные из файла и несем их в скрипт 2 (сборщик данных). При инициализациях объектов в _ready разных объектов тащим из него данные.
Ощущение, что шаг 5 не самый надежный. Типа если игра оформит вылет, то файл с сохранением похерится.
Правильно понимаю, что для шага 5 нужны до действия:
5a) Имеем два файла сохранения - основной и временный
5б) В момент записи прогресса записываем его во временный файл
5в) Делаем какой-то сигнал/флаг/etc, после записи данных в файл
5в1) Если этот сигнал не сработал, то считаем, что запись в файл не была завершена. Значит основной файл сохранения не трогаем
5в2) Сигнал получен -> запись успешна. Меняем временный и основной файлы (через переименование?)
Но все еще остается слабый момент в п.5в2
>4) Скрипт 2 (сборщик данных) дергает все на уровне все, что может сохраниться и записывает это к себе
Вот тут поправка. Дергает это не автолоад, а родительская нода всего уровня и сама уже сохраняет в autoload через что-то типа:
func Collect_level_data():
....level_data = []
....for node in current_level.get_children():
........if node.is_in_group("test_objects")
............var test_object = {
................"node_id" : node.node_id,
................"node_position" : [node.global_position.x, node.global_position.y, node.global_position.z],
................"node_rotation" : [node.rotation.x, node.rotation.y, node.rotation.z] }
............level_data.append(pushed_object)
........G_Data_collector.game_data["levels"][current_level.level_name] = level_data
>Ты тоже "ad hominem" загугли
Что, обидно, каргокультист?
>Будут - в будущем, поэтому я и предлагаю избегать их заранее.
А если не будут? И ты нихуя не предлагаешь, только пишешь свои нахуй не нужные ноющие пасты, не назвал ни одной методологии как писать без синглтонов. Даже шину событий не назвал, хотя мое имхо - шина это даже хуже чем синглтон, потому что вместо явных связей получаем неуправляемый слабосвязанный пиздец.
>ECS для геймплея не нужен, его роль - оптимизации кэша процессора, которые в геймплее работать всё равно не будут, если у тебя хоть сколько-нибудь сложная игра с нормальным количеством механик и вариаций объектов.
Ну да, использование "книжного" ecs обычно этим и ограничивается.
>Впрочем, из-за ECS у тебя вряд ли сложный геймплей.
Сессионка с разными режимами, лобби, магазом и заданками - достаточно несложно? А ведь это еще не самое интересное. Например, благодаря ecs, я могу неиронично программировать геймплей конфигурационными файлами, такими как на пикриле. Да, не добавляя при этом ни строчки кода. Захотел - дописал что в определенном режиме у определенных игроков при определенных обстоятельствах появляются определенные компоненты с определенными свойствами. Могу с нуля создать режим просто набором конфигураций.
https://www.youtube.com/watch?v=70OkbSn0KlM
Боишься что твой код нагенерированный чатгпт украдут?
Уровень разработке в инди геймдеве настолько низкий, что укравший идею проф. программист - напишет с нуля код лучше чем ты.
Ты чтоль? Про тебя не переживаю, ты украв идею будешь ее архитектуру пердолить до собственной могилы.
Ну да, возьми путь к ящику от owner ноды сцены как ключ доступа к твоему ящику, и сохрани стейт ящика когда пойдет сигнал "save_level" по этому ключу. Если делаешь годот лайк сигнальный кал это самый простой и логичный способ. Если у тебя архитектура сложнее - там уже сам думай.
>если архитектура сложнее или ты используешь любую форму процедурной генерации ящиков
быстрофикс
А теперь представь что тебе надо сохранять-восстанавливать вообще все. Пуля летит? Сохраняй скорость, направление, ее состояние. Ящики? Сохраняй. Сундук? А открыт ли он? А что если игрок сохранится в процессе открытия сундука? А если пока открывает ворота? Или пока нпс кастует заклинание? А если у тебя еще и физика есть, и какая-нибудь монетка летит по инерции в игрока? И все это взаимосвязано? А? А? А?!
Ебучие сохранения. Худшая часть геймдева нахуй.
У ящика есть два состояние - целый и разбитый, сохраняй эти состояния, потом загружай сразу разбитый вариант.
Спасибо
>>1052809
Не спасибо
>>1052811
Да, я вижу два подхода, иметь дефолтный ящик на уровне и менять его состояние или, то что ты говоришь, не иметь ящика и загружать илин е загружать его, но в этом случае теряется WYSIWYG часть редактора, будто усложнение себе жизни
Лол блять, мистер мультиплеерные кнопки, вали обратно в свой загон, тебе тут не рады.
так даже аааа не делает как ты описал
Шизло, успокойся. Просто не нужно давать возможность сохраняться каждую секунду
Я не он. Все всё делают. Я вот недавно в первого Макса Пейна переигрывал, там по ф5 сохраняется вообще все, летаящие пули/гранаты, состояние брошенного и разбитого коктейля молотова, состояния дверей, анимация, даже войслайны сохраняются нахуй. Сохранившись в перестрелке и откиснув микросекундой позже я гарантированно откисну снова, загрузив этот сейв, потому что в мое ебало уже летят убьющие меня пули, а мой персонаж находится в прыжке и никуда я его не дену.
>>1052815
Деды давали. Вы просто ленивые жопы, манямирок себе придумали.
>Mакс пейн
>4+ года разработки на полный рабочий день
>6 рыл в разрабах
>Графика по меркам 2025 вызывает либо отвращение либо ностальгию, игровой процесс туда же
Слышал что-нибудь про расстановку приоритетов?
>так даже АААААА не делоют!
>ну нет ну это друхое
Я тебя услышал, маняврятор. Потерянные технологии древних. Опять.
Новые игры тонут в мире ассетфлипперов как американские морпехи под омаха бич, как бы ты там не извращался с сохранениями. Новое время, новые веяния. Сделал больше и быстрее ценой никому не интересных мелочей - победил. В сиквеле если игра зашла - можешь уже любой хуйней страдать.
Я не он, но Макс - реально не оч удачный пример. Не тянет на АААААА своего времени. А вот Халф-Лайф 2 очень даже тянет. И делает всё то же самое.
Осло, ничего сложного в подобных сохранениях. Просто каждому сохраняемому объекту даём функции to_save и from_save, в них и описываем, что переменно и должно быть сохранено, а что нет. При сохранении опрашиваем всех, собираем инфу. При загрузке:
1. Создаём тех, кого не существует, но инфа есть,
2. Опрашиваем всех, восстанавливаем состояние,
3. Загружаемый объект есть, а инфы нет - удаляем его.
Сохранить анимации - две записи: имя анимации и текущее её время. Сохранить пулю - тип пули, кто её выпустил, положение, скорость. И так далее.
Может быть какой-то мировой объект, хранящий общее состояние игры (какие-нибудь квестовые переменные, например) - общаемся с ним через to_save и from_save точно так же, как с каким-нибудь ящиком.
Можем не ходить по всем объектам при нажатии сохранения, а складывать инфу о них в мировой объект при каждом их состояния. На метод загрузки это не влияет, зато при большом количестве сохраняемых объектов поможет избавиться от фриза по F5. Не очень подходит, если нужно сохранять много физических штук.
При выходе с уровня можно собирать всю инфу о его содержимом и складывать в мировой объект. При заходе обратно - загружать её оттуда, будто из сейва.
>>1052819
>>1052809
>>1052816
Шизики, вы сначала скажите, нахуя в вам с точки зрения гейм/лвл-дизайна сохранения в любой момент?
Функционал ради функционала не делает игру лучше
> Может быть какой-то мировой объект, хранящий общее состояние игры
Вот вам world.gd в псевдокоде:
> class_name World extends Node
> var world_data : Dictionary = { }
> func load_from_file(path): var data = File.open(path, READ).get_string(); world_data = JSON.convert(data)
> func save_to_file(path): FIle.open(path, WRITE).store_string(JSON.stringify(world_data))
Конечно в реальности строчек будет больше.
Обычный функционал быстрого сохранения / загрузки. В большинстве пека игр он всегда присутствовал, и стал отваливаться только с приходом кроссплатформы с консолями. Ты, видимо, слишком мал чтобы это помнить.
>Не тянет на АААААА своего времени
Так в этом и суть пойнта. Анон утверждает что даже ААА такое не делают, тогда как компашка 6 задротов, с бюджетами настолько мизерными что приходилось швабры вместо пушек использовать, это без проблем осилили.
Я недавно понял, почему так. Почему в старых играх зашкаливающий интерактив, в том числе в вопросе сейвов, когда в сейве сохраняется парамеры летящих пуль.
Потому что раньше не было игровых редакторов. Игры писали в IDE. Кодом. Без выебонов с перетаскиванием мышкой визуальных блоков на блоки в блоки. Сцена конструировалась в тогдашних максах-майях, а затем при помощи кода создавалась аналогичная сцена в программе-игре. Разумеется, при полном доступе к этому процессу программист имел возможность создавать сразу интерактивные инстансы сущностей. Как бы это вам обеснить-то. Вот в недавно выходящих ААА играх например, встречаются сервированные столы с тарелками и едой, и эти столы - нерушимый монолит, каждая виноградинка в чаше это бетонная стена, о которую разбивается автомобиль. Статикбоди.
Вот и думойте.
Чел, раньше выход игры уровня макса пейна практически гарантированно окупался. Сейчас это далеко не так. Буквально незачем страдать хуйней и делать эти мелочи если ты знаешь что всё это тебе не может ничего гарантировать, что игра про банан будет висеть в топе, а ты пойдешь на дно вместе со своими "правильными" сохранениями. И дело тут не в ide. Просто на рынке стало тесно, и начало действовать правило "кто успел тот и сьел". Даже если у тебя будет супер нетипичная, проработанная, интересная игра - ты все равно не можешь быть гарантирован от провала.
Про Халф-Лайф 2 ты сознательно проигнорил или в контекстное окно не влезло?
Дедуль, то, что раньше всем было похуй на механику сохранений точки зрения геймдизайна, не значит, что это хорошо. Трава раньше не была зеленее, у тебя просто хуй стоял.
Half-life 2 - это аттракцион с постоянно меняющимися головоломками/боями/условиями. Сохранения в любой момент для такого окей.
А в каком-нибудь survival horror невозможность безопасно засейвиться увеличивает напряжение и последствия от необдуманных действий.
Ты как чукча, видимо - не читатель
>>1052840
>>1052843
Я рад что ваше коллективное "невозможно, никто не делоет" так быстро трансформировалось в "нинужно, все банан делают и ты делай". Хоть немного да обучаемые.
>Я рад что ваше коллективное "невозможно, никто не делоет"
А кто написал что невозможно? Никто не делает - факт. Я буквально не могу вспомнить ни один крупный релиз за последние 7-10 лет, дающий возможность сохраняться в любой момент кроме игр беседки. Ведьмаки просто не дают сохраниться в бою, потому там нет сохранений со спеллами. Игры с автосейвами типа дарк соулсов тоже откатывают мобов в дефолт. Это не невозможно, но судя по всему - никому не нужно, все хавают и так и просят ищо.
> кроме игр беседки
И то потому что там легаси движок из тех самых времён. Если бы Тодд перешёл на анрил, там бы тоже резко на сейв-слоты перешли.
Ну окей, третий балдур забыл добавить, но я хз насколько они там проработанные.
Найс ты жопой виляешь.
>аррряяя делайте
>как зачем? арряяя
Сейчас бы тебя, безыгорку, которая в играх не разбирается, слушать
>не дают сохраниться в бою
Чтобы что блять? Убить весь челендж от сражения?
>Игры с автосейвами типа дарк соулсов тоже откатывают мобов в дефолт
Буквально на этом строится геймдизайн
Пиздец я с дебилами сижу в треде
Ты куда воюешь то? То тебе подавай супер детальные сохранения, то не подавай.
>Чтобы что блять? Убить весь челендж от сражения?
Ну в максе пейне убили же? Или это другое?
Та ты и так никогда нихуя не покупаешь, так что ты как клиент не интересен.
>Буквально на этом строится геймдизайн
Ой, прости, я только сейчас понял что ты не знаешь как работают автосейвы в дс. Хочешь демонстрации - подойди к мобам и выйди из игры, получи свои "детальные" сохранения. И так везде где не чекпоинты.
Я не ебу про что ты.
Сохранения, как и все остальное в игре, должны отвечать требованиям геймдизайна. Если в диздоке (считай в концепте игры) указано, что сохранения должны сохранять все, то они должны сохранять все. Если в диздоке указано иначе, значит делать нужно иначе. А чтобы это прописать в диздоке, нужно turn on мозг и подумать, как, что и зачем будет выполнять ту или иную функцию, в т.ч. и сохранения.
Они, как и все остальное в игре, не существуют в вакууме.
епты бля
Таблетки, шиз. Никому твои детальные сохранения нахуй не всрались
Так в макси пейни жы сделали! И в халф лайф 2! Значит делай и у себя, а иначе игра не игра. Понял?
>>1052867
Не туда воюешь
>Так в макси пейни жы сделали! И в халф лайф 2!
И практически во всех нормальных играх. Епта, даже варкрафт 3 имел быстрые сохранения-загрузки. Судя по твоей бурной реакции ты реально дите, привыкшее к ленивым разработчикам.
Ты сейчас литералли мем. Не забудь обмазать свой деревянный слоп DLSS/FSR и накинуть TAA для той самой кинематик мыльности и статтеров. Сейвы? Интерактивность? Да кому это нужно.
Игры делятся только на два вида - утонули и расхайпились. Игроки такие говноеды которые купят даже если игра будет крашить и вылетать раз пару часов если она до них дошла и им понравилась. Я ни разу не слышал чтобы кто-то хвалил механику полных сохранений, кроме шизов итт. Интерактивность - это геймплейная механика и возможно заслуживает человекочасов. Сейвы - возможно в редких исключениях требуют чего-то больше чем сейвы позиций всех активированных мобов, позиции игрока + основные параметры и состояния сумки игрока (плюс квесты и прочая статистика).
Додикс, слово "геймдизайн" тебе знакомо? Либо ты тролишь тупостью, либо ты реально имбецил
Все так, хуевый геймдизайн вокруг своей неспособности в нормальные технические решения. Похоже на те истории времен слабых консолей в 30 фпс, когда со всех сторон заливали что 30, а то и 24, это дизайнерское решение, как в фильмах.
Вытекай по-нашему. Опенсорсно.
Алиса, я несколькими постами выше в подробностях расписал, как делать сохранения. Хочешь - сохраняй всё. Хочешь - не всё. Никаких ограничений. И это можно делать на абсолютно любом движке.
Олсо, всем участникам беседы ИТТ рекомендую упырить мел и поиграть в Кенши. Вот уж где сохранения через жопу сделаны, вот уж где лучше бы Крис поступил по принципу
>>1052878
>геймдизайн вокруг своей неспособности в нормальные технические решения
Было бы гораздо лучше, чем пытаться надендрофекалить что-то вопреки этой самой неспособности.
>это лучше чем пытаться надендрофекалить
Не согласен. Это чаллендж, от которого современные разработчики бегут, как и видим по ИТТ. А без чалленджа нет развития. Поэтому геймдев уже не просто стагнирует, а деградирует.
Но ничего. Пройдет еще несколько итераций технологического прогресса, в какой-нибудь ААА УЕ7 завезут готовую приблуду для сохранения всего в любой момент, и фича квиксейва/лоада снова станет стандартом, а местные будут ее переоткрывать как впервые. Вспомните еще мои слова.
> Это чаллендж, от которого современные разработчики бегут
В чём неправ?
Та во всем прав. Осталось еще добавить "каждый уважающий себя инди разработчик должен написать свой движок и свой язык программирования а иначе не считается", и будет целостная картина.
ну а если серьезно - мне по кайфу что такие шизики есть, это значит что пока они будут дрочить сохранения - у меня будет больший обьем рынка потребителей, которым я доставлю контент быстрее за счет экономии времени на маловажных деталях игры. Хотя скорее всего это обычный залетный безигорка.
>чаллендж
Сама система за один вечер делается. Ух какой чаллендж.
Олсо, пассаж про "надендрофекалить" относился исключительно к Крису Ханту. Если у анона руки хоть на градус прямее - пусть пилит нормальные сейвы.
Помню был где-то тут тред геймплейных идей, но не нашёл его, поиском, по каталогу, никак не нашёл. Так что оставлю это здесь.
Рукастый челик на станках выточил вот такой замочек https://www.youtube.com/watch?v=FeIqdPtL0Cs
Потратил много времени всего на один вариант. А я тут подумал, в играх можно налепить целую кучу подобных фигурных замков-матриц, чтобы ещё эти матрицы вставлялись в специальный нажимной-поворотный ключ. Потом игрок ходит по уровням, находит матрицы, может их в инвентаре поразглядывать, прикинуть, куда какая подходит.
Ящитаю такие штуки играются лучше в физическом варианте, чем в цифровом. Потому что их геймплей во многом базируется на "потрогать".
Не ну тут без базара, да. Но заметь, тебе ещё не скоро предоставится возможность побродить по таинственному особняку с загадочными матричными замками на дверях, периодически прячась от хтонической йобы. А в игре - пожалуйста.
Ну в резиках что-то такое есть.
Можно добавиь 3d модельки на покрутить, понажимать, потрогать. Нормально
Почему студии 10 лет хуярили соулс-лайки, и ни один мудак не запилил резидент-лайка, кроме оригинальных афторов, которые 10 лет ремейки лепят и которые у них разбирают как горячие пирожки?
Я давно хочу вот такую сделать. Будучи школотой имел эту ручку с шариком внутри, залипательно было по 3д лабиринту его гонять.
И реализовать на годоте предельно просто.
Потому что это сложно. И не в плане разработки и кода. А в плане геймдизайна. Все продумать
Тема неблагодатная. Я например в рот ебал ужасы, и так нервы ни к черту и мои знакомые тоже в ужасы не играют. Дед спейс, резики, алиен изолейшен, scp - это не про них и не про меня. Потому имхо никто и не лезет.
>>1052951
Ну и согласен с аноном, ужас без скримеров это уметь надо.
>и так нервы ни к черту и мои знакомые тоже в ужасы не играют
Клуб благородных дев за 60?
>Тема неблагодатная
Хорроры, что в кино, что в играх стабильно собирают кассу. Это буквально классический базовый жанр индустрии развлечений
только если это хорроры сделанные с 0 бюджетом для стима
Все большие хорроры буквально проваливаются один за другим, кроме резидентов
Потому что ААА боятся рисковых решений, которые необходимы для качественного хоррора.
> рисковых решений, которые необходимы для качественного хоррора
Примеры в студию.
Мне Iron Lung зашел, но и идея и реализация слишком bare-bones чтобы ААА за нее взялись.
>деньги на полноценного художника коплю
Не рекомендую. Проебешь деньги, а проект все равно забросишь - двойная боль. Рекомендую делать самостоятельно. Лоуполи, нейронками, прокачивая скилл - похуй как, но сам.
Тем более, современные художники не умеют работать по текстовым описаниям. Я неоднократно проводил тестирования в рисовач-тредах и там никто не смог правильно нарисовать эскиз по моим описаниям.
Используй готовые ассеты для прототипирования. Готовые модельки нужны уже на поздних этапах. Как раз, когда деньги будут
Блядь, пример далеко не лучший. Когда вижу такое - сразу подозрение что на дворе 2009 а я наконец закончил проходить ТЧ. Есть примеры по графике на годоте и получше.
Ну я к тому что хвастать нечем, графон уже смертельно устарел. Свой не покажу, да и он 2д
Просто взял скрин с реддита. Чел как раз спрашивает как ему улучшить графику. Можешь сходить рассказать: https://www.reddit.com/r/godot/comments/1nn5rvy
>Когда вижу такое - сразу подозрение что на дворе 2009
Минусы будут? Вот лишь малый список игры из 2009 года:
- Call of Duty: Modern Warfare 2
- Dragon Age: Origins
- Left 4 Dead 2
- Prototype
- Borderlands
- Resident Evil 5
> Есть примеры по графике на годоте и получше.
Нахуя? Графодрочер хуже червя пидора. Никакого значительного прогресса в графике после выхода первого(!) Crysis и до сего дня не было. А недавний бум low-poly/psx style инди игр в очередной раз доказывает, что арт-дизайн > кол-во полигонов.
>>1053071
Для начала - убрать 32 полигонный прицел с глаз долой. Кусты - спрайты - в 2к25 это уже не смешно. Ветви деревьев слишком плоские, им бы нормаль запечь высокополигональную, чтобы оно хотябы делало вид что имеет обьем. Снег не имеет зернистой нормали и обладает слишком низкой металличностью, из-за чего похож при освещении на хер знает что (на текстуру снега из скайрима). Это для начала.
>улучшить графику в годоте
С ума сошел? Пропуки будут адские
Зачем кому-то слушать безгеймплейного графодрочера вроде тебя?
Ты чего, обиделся что ли? Пропуки в годоте это не какой-то мем, а суровая реальность, с которой разрабу приходится считаться. Манямирок от пропуков не спасет.
Блин, ну это же реально посильная задача даже для годота. Сделать это - и уже игра не похожа на говно. У игры нет стилизации которая бы оправдывала такую степень слабости растительности в отношении детализации, автор нахуярил деталей, но детали сами по себе не работают, картинка выходит нецелостная. Тем более в 4 уже есть нормальное освещение, есть где развернуться, в 4.5 появились изогнутые нормали.
>У игры нет стилизации которая бы оправдывала такую степень слабости растительности в отношении детализации, автор нахуярил деталей, но детали сами по себе не работают, картинка выходит нецелостная.
Ну значит автору нужно копать с сторону красивой стилизации
А не в сторону
>нормальное освещение, есть где развернуться, в 4.5 появились изогнутые нормали.
Т.к. инди-говнокодер вроде меня не вывезет в качественную оптимизацию.
так автор же написал
>I am making a realistic game
значит, кусты-билборды в топку. хотя мне самому такие нравятся. это как театральные декорации, они не обязаны быть реалистичными
Оригинал не читал. Но тут может речь идти и просто про "реализм" в плане сеттинга или механик.
Начнем с того что сцена сама по себе содержит координаты расставленых обьектов, загружай сцену сразу. Если нужно билдить самому неприменно - напиши tool скрипт который сериализует обьекты сцены в какой-то удобный тебе формат. Закончим тем что непонятно какую проблему ты этим хочешь решить. Если ты уже создал карту и расставил обьекты - просто сохраняй и загружай ее в рантайме.
Есть охуенная тема, называется MetaMultimeshInstance. Базарю, еще захочешь. В принципе такую тулзу можно и самому себе написать. Но зочем, если оно уже есть в ассетсторе?
У меня ещё вопрос. Кто как раскрашивает свои карты? Ну, которые базовый ландшафт. Я, честно, в душе не ебу как рисовать по большому мешу текстурами, типо как травку всякую, где-то камушки, где-то тропинки. Это по моему называется Vertex painting, но я вижу изкоробки такого функционала в годоте нету.
Не, я ничего не расставил, у меня есть объект, отждельной сценой. На сцене уровня таких объектов может быть много, уровень я загружаю передавая массив координат таких объектов. То есть нарпимер мне надо на ыцене уровня создать 10 объектов, расставленных заранее известным образом, например как точки, по которым рисуется картинка, я не знаю, три точки треугольник. И вот я ъочу нарасставлять разных треуголников, квадратов и тд. Делать их отдельными сценами вручную это тупо. Мне нужны просто координаты, которые я вставлю в уровни
>расставленных заранее известным образом
Т.е. это не пвсевдорандомная генерация уровня? В чем проблема просто в редакторе создать сцену со всеми объектами сразу?
Чет я не врубаюсь, что ты хочешь. Опиши конкретный кейс
Нет. Представь, есть 10 объектов, для простоты, это точки. Они хаотично расставлено на сцене, пользователю надо найти например все возможные треугольники, соединяя точки. Но только они не рандомны расположены, а их расположение известно заранее, мне нужно эти рисунки просто в координаты переводить, ну или каким-то редактором расставлять и получать координаты. Конечно можно создать 100 сцен таких как 100 уровней и в реадкторе вручную расставить, но это как-то тупо
> но это как-то тупо
Почему же тупо? Вон авторы игор хвастаются вручную расставленными уровнями.
Если фигура заранее известна, то тупа находишь центр координат, спавнишь туда объект, выравниваешь ротацию по одной из точек. Или сравнишь угол на одну из точке и дальше снова выравниваешь ротацию.
Если фигура неизвестна, но создаешь mesh через код и натягиваешь текстуру
> Снег ... обладает слишком низкой металличностью.
Ох эти любители отражений, даже на матовых поверхностях.
Куда ты будешь перетаскивать элементы в отфильтрованном списке? Просто задай себе вопрос, куда следует поместить элемент, когда список перестанет быть отфильтрован?
Вот пикча. Чёрный список исходный. Красный отфильтрован. В красном перетащили один элемент. Покажи как будет выглядеть список при отключении фильтра?
Представь что на уровне много элементов, среди них есть HorseStable, и я хочу перетащить Horse под него - сделать Horse ребенком HorseStable. И вместо того чтобы брать Horse и вручную скроллить все древо нод, я вбиваю Horse* в фильтр, и вижу только нужные мне ноды, и перетаскиваю одну в другую. А теперь представь что таких Horse у меня два десятка.
Что? На моей пикче проставь буквы в чёрный квадрат. Ты способен осознать задачу и проблему? Хуле ты мне лепишь горбатого?
Африканец чтоли? Ты снег то видел под солнцем? Он ебашит в глаза так что щуриться начинаешь и переливается тысячами бликов. Конечно просто металличность накидывать не надо, это не лужа. Но металличность + нормаль которая создает "снежный" рельф, который как будто порошком посыпан - будет заебись.
Зумеры насмотрелись на снег в играх и забыли как он выглядит в действительности. Поколение одаренных.
У него яркое, но матовое отражение. Блики только если образовалась кромка льда (таял, замерз, но такое не часто в северных регионах).
Тут солнце то ли глубоко закатное, то ли за облаком. Поищи где солнце светит в зените, как это в той игре.
Там вообще пасмурная погода и закат (смотри на длину теней).
Прав был тот анон, что зумеры не могут удержать контекст двух трех сообщений. Ты меня сам просишь посмотреть то, что противоречит тебе.
Где тут металлическое отражение? То что снежинки могут бликовать мы знаем, но это только в зуме, зумер.
>как писать без синглтонов
Тебе - никак, ведь ты
>благодаря ecs
- ецс-шиз.
Выучи ООП - поговорим.
На втором пике закат? Окей ебать. Пасмурно - это когда теней нет, поскольку источник света светит как бы из всего неба. Есть тени - значит источник света есть, извольте блики. Если автор за каким-то хуем нарисовал туман (или бурю, хз) это еще не значит что пасмурно.
>>1053290
>но это только в зуме
В хуюме. То что камера дерьмово передает блики в отдалении это еще не значит что их там быть не должно, а автор хочет реализм (не фотореализм кстати, это разные вещи).
>>1053312
Шиз спок, освой аргументированную дискуссию и приползай
>освой аргументированную дискуссию и приползай
Тогда я не буду делать игру. Сидите тут без игр...
>Если автор за каким-то хуем нарисовал туман (или бурю, хз) это еще не значит что пасмурно
Африканец не знает про морозную дымку.
>камера дерьмово передает блики
Камера виновата что снег не металл, запишем.
>Пасмурно - это когда теней нет
Там скорее всего рассвет. Но есть туман от дымки.
>Есть тени - значит источник света есть
Если ты видишь что-то вообще - источник света есть всегда.
Поводил тебе металлическим бликом, по шершавым матовым губам. Бестолочь. хватит маняврировать на анонимном форуме, обосрался, тихо слейся и все, всем похер на тебя, покормил последний раз
>Африканец не знает про морозную дымку.
Ну окей, в сибири я реально не был. У меня тут такого не бывает.
>Камера виновата что снег не металл, запишем.
Я тебе в приближенном показал чего камера не рисует на твоих пиках, ты начал маняврировать про "только в зуме"
>Поводил тебе металлическим бликом, по шершавым матовым губам
Играть в нет ты не буду. Графика говно, пускай переделывает. Хотябы своими глазами пускай на снег посмотрит.
Ладно, я сдаюсь. Блики снегу похоже вообще никто не делает, хотя лично мне всегда из-за этого снег в ирл казался намного круче чем где бы то ни было. Вряд ли я один такой шиз который их видит без всякого зума. А жаль, я думаю их реально сделать.
Это не блики, это искристость. Достигается эффектами постобработки.
Спасибо анону с фикс моего косноязычия.
>>1053288
https://www.artstation.com/blogs/agatha00/320q/week-6-shader-museum-procedural-snow-shader
Вот такое надо. Есть небольшой эффект металличности у снега + блики.
Несколько нод разом переносить умеет, 2д/3д трансформ сохраняет. Удобно. Осталось говнокод подчистить и причесать.
> накатать плагин для фильтрованного "перетаскивания" по дереву нод
Во всём прав.
Есть коллижн лейеры, но я их уже и так использую для разных категорий тел, типа слой 1 — персонажи, слой 2 — окружение, слой 3 — атаки, и так далее. Чтобы добавить слои для разных этажей, мне придется срать слоями типа "окружение на втором этаже", "прожектайлы на пятом этаже", "враги в подвале", что есть ебля.
При каждой обработке коллизии проверять, на каком этаже тело — еще большая ебля, учитывая что в разных скриптах у меня разные функции обработки коллизии, да и к тому же я все равно не смогу так повлиять на вещи типа move_and_slide. Че делать? В три дэ переходить?
Физ движок живёт тока слоями, поэтому нужно изъёбываться, а именно - этажи находятся не на разных слоях таилмэпа, а в разных координатах 2D мира + выебоны типа visibleonscreen
Первый этаж виден игроку, когда он на втором? Потому что если нет, можешь его сдвинуть нахуй с экрана и подальше от игрока. Да и если виден - можешь все равно сдвинуть нахуй, поставить над ним вторую камеру, и скормить фид с нее анимированной текстуре, которую положишь под второй этаж.
А еще я люблю 3д. Наебался с топ даун 2д, несколько проектов сделал, и скажу что 3д лучше.
Я подумал, в теории есть ещё вариант, каждый этаж пихать под вьюпорт, ему можно задать собственный World2D, но хуй знает, никогда не видел, это в теории
Загружать выгружать чанками/уровнями/сценами. Открыл дверь - темный экран, вот персонаж стоит уже внутри второго этажа, первый этаж выпилен.
Тодд Говард одобряет.
Обрати внимание. У тебя референс в перспективе нарисован, а моделька мекйхумана в изометрии. Афторы мейкхумана в целом молодцы, но у них есть шиза насчёт изометрии, они считают, что "профессионалы" с перспективной проекцией не работают. Поэтому перспективную камеру туда можно завезти только через аддон.
И ещё раз, поскольку 99% референсов являются скриншотом перспективной проекции с тем или иным фокусным растоянием, ты не сможешь достоверно по референсам воссоздать персонажа. Так что ставь аддон. Он гуглится с полпинка.
А вечером посмотрю, как это в годоте применить. И в своих игорах.
Так и надо. Каждая группа этажей расположена на отдельном вьюпорте в разных мировых позициях, а игрок при переходе между этажами просто тпшится.
Там про жопы. Как в годоте применить - делайте жопастых годетт.
> а игрок при переходе между этажами просто тпшится
В смысле репарентится между вьюпротами?
Ну глобально его координаты меняются, в этом смысле. Поскольку в годот 2д такого понятия как z нет - тебе придется раскидать разные этажи(разделенные по физике) территориально в разные места и телкпортироваться между ними, чтобы находиться в них, а много вьюпортов будут создавать видимость что ты как будто бы находишься в стопке из этажей, хотя на самом деле на экран просто накладываются и подкладываются изображения из вьюпортов, снимающих уровни по отдельности.
Знаешь что особенного в этом графике (кроме того что это нормальное распределение по Гауссу).
То что самый популярный и красивый вариант для участников это 4, но в тоже время в совокупности большинство не выбрали вариант 4 (он не самый красивый).
Что это говорит? Ничего, красота ппц как субъективна. И если хочешь попасть в максимальную аудиторию, тебе надо создать не 4 вариант, а варианты 2,3,4,5,6
И автор вроде некорректно разбирается в золотом сечение. Но спекуляция в этой теме действительно есть.
Хочешь совет на миллион долларов? Нужно просто три раза в день делать...
Опять забайтили на пустое видео, лалки. Спасибо богам ютуба за скорость х1,75
Чтение текста (у меня) отнимает больше мозгового дневного потенциала, чем слушать/смотреть видос на фоне. Не хочу уставать на букофках, да еще гпт врёт часто.
>У тебя референс в перспективе нарисован, а моделька мекйхумана в изометрии
Ну справедливости ради, перпектива ебет впуклость-выпуклость, сам силует перспектива ебать не должна, если мы рассматриваем равноудаленные от камеры точки. Сулэт - это в принципе единственная истина о форме которая у нас есть, когда мы что-то лепим или срисовываем. Все остальное - иллюзия той или иной степени и зависит от дохуя всего.
Справедливости ради пользователям следует предоставить все виды проекций, а пользователь пусть сам выбирает. Я пишу именно о том, что авторы мейкхумана взяли на себя смелость решать какие проекции пользователям не нужны. Впрочем, это давно было, надо проверить, может им уже вправили мозги.
Поэтому я тебе ИТТ всегда пишу длинные полотна. Чтобы ты уставал от текста и игры не делол.
Анонче, может, ты попробуешь MPFB2 вместо MakeHuman? Это то же самое, но в виде аддона для Блендера. А уж там любую перспективу делай, какую хочешь.
Изучили вопрос. Это охуенно! Спасибо. Забираем в продакшон.
@
ЩАС ПОСМОТРИМ ЧТО ТАМ
@
@
@
ПОНЯТНО, НИЧЕГО НОВОГО
Бамп >>1052238
https://www.youtube.com/watch?v=h6KLlb-4j3s
Годот потихоньку подбирается к пастгену, но эти отражения света просто пиздец какой-то, нахуй ее черепушка с волосами такая отражающая?
А я тоже присоединюсь к расспросам. Ты работать пробовал?
>>1053863
Аноны, ну это же реально пиздец какойто. Вы это будете дефать?
> Вы это будете дефать?
>>1053861
> черепушка с волосами такая отражающая?
Чел тупо не знаком с картами шероховатостей. А виноват у него кто? - Правильно, движок.
>Правильно, движок.
Где я сказал что виновато двигло? Нигде не сказал. Даже если забыть об этом - все равно пастгеновский графон.
> Где я сказал что виновато двигло?
В срачезагоне, из которого ты посмело выкатиться в приличный тред.
Ну малаца тогда, хуль. С тобой мои синглтоны.
https://www.youtube.com/watch?v=spBakIGn55E
Важно не забывать, что программирование всего лишь инструмент, а не самоцель. Аналогично и с чатботами. Не нужно позволять чатботу думать за вас, нужно его использовать как дополнительный инструмент.
Самый главный подводный камень - игры уровня ЖТА 3 требуется делать многопоточно, а ты в многопоток не сможешь.
Нету стриминга ресурсов сцен, потому что нету террейна, а террейна нету потому что пока что заниматься плагинами террейна в движке может только 2 автора этих самых плагинов, один из которых полностью переписал кусок работы с ресурсами в обход того что сделано в движке. Возможно как mterrain лучше прокачается - под такие плагины создадут движковые механизмы позволяющие цепляться к стриму обьектов сцен, тогда возможно появится возможность без геморроя делать большие опенворлды. Либо форкай движок и внедряй стриминг сам. Либо ограничивайся лоуполи.
https://youtu.be/ZUXAuhoPV5k
Ну вот собственно иранец, который по факту поверх движка написал свою систему ресурсов с поддержкой стриминга, можно попробовать собрать ландшафт гта на базе его торпедного велосипеда, а остальное делать обычным способом.
А что ты многопоточить в гта собрался? Там кроме навигации и прочих числодробильных побочных легко синхронизируемых операций многопоточить больше нечего.
Он там террейн называет трейном, а в комментах какой-то пидарас его этим подьёбывает, пишет "найс трейн", гнильё ебучее.
Стриминг чанков террейна, например. И весь остальной стриминг ентитей и систем.
>Стриминг чанков террейна, например
Террейн сам это дело в своих кишках разруливает, так что мимокрокодилу лезть в такое по идее и не надо.
>стриминг ентитей и систем.
Это вообще что? Стримить npc не надо, они в оригинальном гта управляются стандартными ручными способами. Если же ты намекнул на ecs - делать ecs для гта реализовывая книжный вариант - простой способ возненавидеть этот подход и больше его никогда не использовать. За исключением одного варианта его использования, но о нем (или о его аналогах) знает возможно пара человек на свете.
> Террейн сам это дело в своих кишках разруливает, так что мимокрокодилу лезть в такое по идее и не надо.
А куда надо лезть сеньору-разработчику?
Взять террейн от иранца, НПС от испанца, машины от немца, деревья от поляка. И затем всё вместе положить. Охапка дров - и ЖТА готов!
>А куда надо лезть сеньору-разработчику?
>Взять террейн от иранца, НПС от испанца, машины от немца, деревья от поляка. И затем всё вместе положить. Охапка дров - и ЖТА готов!
Минусы будут? Инди геймдев выглядит именно так и никак иначе. "Я его слепила из того что было". Ну не всегда и не везде, но в массе именно так, отдельные куски игры это работа всяческих иранцев и прочих добрых людей со всего света. Хочешь почуствовать себя сеньором - попробуй выжать из этих наборов повышенную производительность путем ввода сеньорских костылей внутрикодово.
Зачем там стриминг в 2к25? Там крошечная карта с еще более крошечной видимостью, ограниченной туманом. А количество полигонов суммарно меньше чем в одной модельке из какой-нибудь дьяблы 4. Современные пеки тянут такое с 600 фпс, так что можно литералли навалить все в одну сцену и даже лодами не заморачиваться и оправдать это все стилизацией под ностальгию.
Да, на пикриле сиська
У всех нормали нормальные (вон видос выше), у тебя одного пихло виновато.
Не, дак я не говорю, что это именно проблема пихла. Просто я хочу понять как сделать по уму. Явно что-то ломается, но я не могу понять в какой именно момент, пушто экспортирую из блендера я абсолютно 100% пригодный меш.
>сделать игру уровня ЖТА 3
>Какие основные подводные камни?
Для игры типа GTA III нужно МНОГО контента.
Сможешь придумать МНОГО контента?
Я вот попытался и не смог...
Наклепать коробки и коробки на колесах? Хуй знает, сложна.
2001 год, детализация уровня полена.
То то это так легко, что убийцы гта выходят каждый год и убивают гта уже в 100500 раз, ога
Так выходят убийцы гта 5, а речь про гта 3. Большая разница. Если не охуевать со скопом и детализацией то вполне реально даже в одно ебло.
Нет, нереально. Один ии нпс чего будет стоить. Ну или реально за n лет, когда уже можно будет в соло убивать гта5, а ты все еще будешь пытаться убить гта3.
Лучше тогда уж сделать что-то типа линейного приключения с миссиями в относительно открытых городских локациях. Типа 1-3 миссии подряд в одной локации, потом с слудющей и т.п. Плюсы в том, что не нужно будет геймдизайнить большой открытый мир. И можно будет последовательно наваливать уникальных для локации геймплейных механик.
Типа можно сделать так:
1) Локация первая - шоссе, придорожное кафе и трейлер-парк неподалеку. Вступительные миссии, обучение основным механикам
2) Локация вторая - пригород (частные домики, парк, какой-нибудь шоппинг мол неподалеку). Тут можно навалить побольше транспортных средств, немного стелса в частном секторе
3) Локация третья - порт (сам порт, какой-нибудь грузовой корабль, склады). Тут добавляем больше экшона и водные мисси
4) Локация четвертая - центр города, богатый район, небоскребы, большие здания. Тут можно сделать социалочку, интерактивности и миссии внутри небоскреба
5) Локация пятая - вокзал, можно сделать миссию на поезде, где первая миссия начинаете в одной локации (город), а заканчиваете в другой (за городом), типа динамичная смена мини-локаций в рамках 2-3 миссий
6) Ну и финалочка - богатый район с частными домами или загородный особняк, где мочишь главгада.
Открытого мира не будет, но зато можно навалить разных локаций с большим кол-вом контента. Меньше головняка с оптимизацией, проработкой открытого мира и т.п.
Можно четко вести игрока по сюжету, меняя локации и механики так, чтобы тот не успел заскучать
> что-то типа линейного приключения с миссиями в относительно открытых городских локациях. Типа 1-3 миссии подряд в одной локации, потом с слудющей и т.п.
Urban Chaos 1999
попробуйте убить его для начала
> кококо, если я напишу узнаваемое имя в названии, будет больше скачиваний
Нет, не будет.
>>1054075
Ебать, какую же хуету вы здесь обсуждаете.
Так там интеллект у нпс простой, прекрасно помню как 3 непися разом в стену бежали. Он там так, чисто для галочки. Вы, видимо, наигравшись в гта 5 накладываете ее качество на гта 3. Короче я не вижу проблем для реализации гта 3 на годоте. Даже стриминг не нужен.
За адекватные сроки в соло можно сделать разве что гта1. И всё равно она пиздецки масштабная, года два фуллтайм работы.
Хочу сделать пиксельный рогалик данж-кравлер в фентези сеттинге и чтобы с шутками про пиво, какие подводные?
>пиксельный
Обосрёшься с пиксель-артом - он не так прост, как кажется.
>рогалик
Обосрёшься с генерацией карт - это сложнее статичных карт.
>данж-кравлер
Обосрёшься с клаустрофобии, пока будешь тестировать игру.
>в фентези сеттинге
Обосрёшься с банальными клише дворфов-эльфов-гоблинов.
>чтобы с шутками про пиво
Обосрёшься с пропагандой нездорового образа жизни в игре.
>подводные
Обосрёшься с жидкостями и плаванием в 2D с видом сверху.
>Хочу сделать
Обосрёшься с желанием делать игру - быстро перехочется.
попытался @ обосрался
Есть риск встретить под водой себя. Со стороны годота ноль подводных, если ты согласен лабать на годотскрипт
Уже есть, скоро выходит. Правда там лоуполи
https://store.steampowered.com/app/1171980/Neverlooted_Dungeon/
>прекрасно помню как 3 непися разом в стену бежали. Он там так, чисто для галочки.
Ну мне чисто для себя такое не ок было бы. Сразу магия игры разрушается
>>1054084
Ну не стукай! Что не так? Ну да, у меня порой фантазия в полет уходит. Никаких минусов не вижу. Вопросы геймдизайна порождают вопросы реализации (т.е. вопросы про GODOT)
https://www.gdquest.com/library/gdscript_formatter/
https://github.com/GDQuest/GDScript-formatter
Пул висит с 2023 года https://github.com/godotengine/godot/pull/76211
Да и форматтеры существуют давно, для vscode-а точно два было уже 3 года назад
> Мнение?
Годно, православно. Иногда после творческих метаний переменные вместе с функциями обьявлены где попало посередине. Вручную их двигать лень (ибо процесс не творческий). Так что приветствуем.
>войдет ли он в базовую поставку годота
Тот, что в >>1054118 написан на расте и может войти только в очко своему автору
Какой резон использовать C# с Годотом кроме как для реюза готовых решений, которых больше в силу универсальности языка? Ну и вообще поделитесь мыслями.
Спасибо тем кто ответит, добра и поменьше легаси макарон
Напомню реальную статистику по языкам в годоте. Пик 1 - 2024, пик 2 - 2025.
Перепостил из предыдущего треда.
ГДСкрипт прост и выразителен. В готовой игре компилируется в байт-код, который исполняется внутри компилированного сишного ядра. Если 6 лет назад там были тормоза и недоработки, то сейчас он как небо и земля по сравнению с прошлыми версиями. Многого ещё не хватает, но и на том что есть можно кодить вполне по взрослому.
> реюза готовых решений, которых больше в силу универсальности языка
Всё равно придётся всё переделывать самостоятельно. Настоящие решения - это алгоритмы и паттерны. А они не привязаны к языкам.
Так что, мой выбор - гдскрипт. Но только если речь о Годоте. Так-то я и на шарпе приложухи лабаю. Там свой каеф.
Да, поэтому из линукса начали вырезать поддержку разных вещей, от старого железа до графических драйверов, растерам видите ли мешает.
Можешь открыть cargo файл форматтера сверху и охуеть от числа его зависимостей, в качестве профилактики.
О, я знаю эту игру.
Что именно тебе такого даёт раст в ядре линукс?
Берешь готовые механики -> думаешь в парадигме "а было бы круто если бы..." -> допиливаешь уже готовую механику
Но нужно быть заряженным знанием, что, как и когда работает.
Да я смотрел уже видосик один из подходов предлагался такой, но он особо мне не помог. Это не объясняет действительно ли это хорошая механика выйдет или нет. Мне больше системный подход нужен и какую-то хоть систему критериев
>>1054177
Если верить ии, то он предлагал группу критериев которые у меня выполняются, но я все-таки склонен что этого недостаточно. К примеру пару критериев это развитие механики, конфликт механик и т.д. Но я бы туда докинул еще критерий удобности управление механики, который я сам для себя создал ( и тут начинается веселье, я хз удобно нет), "фановость" - это я тоже не понимаю как оценивать. Самый легкий способ конечно взять уже готовые механики придуманные людьми и обернуть ее в другую обложку, но это по факту просто копипаст, тогда возникает вопрос, а зачем что-то реализовывать что уже было сделано.
Нннуу, если ИИ сказал, то куда уж нам? Делай как велено.
Шарп это игрушки для больших дядей, у которых свой игровой фреймворк на шарпе, на базе которого они педалят игры. Мимокрокодилу, который едва знает этот язык - лучше освоить гдс. Поддержка у шарпа действительно хуже, но я бы не сказал что шарп не жалуют, философия годота позволяет подключить любой язык в двигло, просто шарп находится на большем попечении в виду большого количества выходцев с юнити, соответственно шарп контрибуторов много, больше чем прочих. Процентам можешь не верить, достаточно глянуть какой процент из прошедших опрос получил бабки за свои игры, и очень хороший вопрос кто из языковых процентов в этом показателе превалирует.
Ну главное, чтобы тебе самому было по кайфу. Было бв тебе интересно играть? Если да, то збс. Значит и другие любители найдутся
>Самый легкий способ конечно взять уже готовые механики придуманные людьми и обернуть ее в другую обложку
Нет, не легкий. С одной стороны ничего придумывать не надо. А с другой нужно не сломать то, что работает, пока это оборачиваешь в другую обложку или комбинируешь с чем-то другим
Но тут нужно еще на проект в целом смотреть. А то можно выдумать прикольную механику, а она повиснет в воздухе и не будет выполнять никаких функций. Механика ради механики - это такое себе.
Типа можно сделать такой флоу:
1) Что за проект?
2) Что я хочу показать игроку? Через что провести его?
3) С помощью каких инструментов это можно сделать? Вот на этом шаге придумываешь механику
4) Анализ механики в контексте проекта
Но опять же. Нужно хорошо шарить в жанре, в котором делаешь игру. Иначе высок риск обосраться
Касаемо самому заебись или нет, то у меня проблема в том что я игровой импотент, я больше 10 - 20 минут не могу играть ни в какую игру все приелось ничего нового уже давно не вижу. Поэтому и главная проблема, что я начинаю что-то новое делать чтоб было самому интересно, но тут не факт что другим зайдет, поэтому и критерием пытаюсь каким-то придерживаться.
То, что ты игровой импотент может сыграть на руку. Можешь буквально от этого отталкиваться - проектировать игру, уровни, механики так, чтобы игрок постоянно получал новый опыт.
Можно даже так делать:
1) Берешь какую-нибудь механику, которую ты считаешь прикольной (в вакууме)
2) Анализируешь, что именно в ней или смежных элементах не так, из-за чего она тебе наскучила
3) Думаешь, как можно улучшить ситуацию
4) Фиксишь, реализуешь, тестируешь сам, возврат к шагу 1
Вообще я тоже ловил игровую импотенцию несколько раз. Помогало только две вещи:
1) Дождаться нового вина, в который будет не скучно играть
2) Поиграть в какую-нибудь бессмертную классику, которую делали люди с прямыми руками и головой на плечах.
С учетом опыта, второй вариант работает чаще
>Открытого мира не будет, но зато можно навалить разных локаций с большим кол-вом контента.
Ты разве не понимаешь, что сшить контент в один бесшовный мир намного проще, чем создать весь необходимый контент в достаточном количестве?
>>1054043
>Наклепать коробки и коробки на колесах?
А ты сам с цветными кубами играть будешь?
Умники, вот сделайте сначала хоть один квартал с достаточной детализацией в 3D, чтоб это не были примитивные цветные кубы, тогда поговорим, как заполнять вашим контентом целый город.
Опенворлд - это чанковая система + контент.
Чанковая система делается один раз и навсегда.
Контент нужно делать постоянно, без копирования.
В противном случае будет очень скучная игра...
>Ты разве не понимаешь, что сшить контент в один бесшовный мир намного проще, чем создать весь необходимый контент в достаточном количестве?
Вот это сказки. Что еще расскажешь?
>В противном случае будет очень скучная игра...
Так ты на шебм атмосферу абсолютно проебал. У тебя скорее пикрил. Но да, ассетов надо больше, и нужна вертикальность чтобы кататься интересно было.
А мне кажется анон прав. Для запила впопенворлда у разраба есть охуенный референс с бесконечным количеством идей, которые можно спиздить - ИРЛ. И больше пространства для левелдизайнерских ошибок. Иначе их бы в ААА не абьюзили так.
Сжимание шакалов размеров билда до 4мб. Обновлено до годота 4.5
А пока вы тут гта убиваете вышел 4.6 дев 1, в основном багфиксы с будущим бекпортом в 4.5.х. Ну еще драг-н-дропать экспорт переменные научились.
>у разраба есть охуенный референс с бесконечным количеством идей, которые можно спиздить - ИРЛ
Спиздить еще не значит реализовать. То-то все открытые миры ТАКИЕ интересные.
>Иначе их бы в ААА не абьюзили так.
В ААА открытие миры уровня "пустое поле - аванпост - пустое поле". Жрите не обляпайтесь. А слова "открытый мир" - это маркетинговый крючок для норми-быдла, который с радостью хавает все, что им впаривают маркетолухи.
Сколько РЕАЛЬНО интересных ОТКРЫТЫХ миров ты можешь назвать? Какая-нибудь локация из пары улочек и домов из какого-нибудь Deus Ex по уровню интересности геймплея ебет стоя целые открытые миры из Far Cry, Assasins Creed и т.п.
Редкие АААА студии справляются с тем, чтобы сделать интересный открытый мир. Соло-индюк с двачей максимум сможет придумать одну механику, а потом сделать Ctrl-C/V по пустой карте.
Есть более-менее успешные примеры, типа Ведьмака, но даже го только ленивый не обосрал за копипастные знаки вопроса по всей карте. И в целом он вывозил за счет другого
Алсо, ты в курсе, что для любых игр идеи пиздят из реальной жизни, лол?
>атмосферу абсолютно проебал
При чём тут атмосфера, если речь о человеко-часах? Независимо от атмосферы, GTA-like требуют много разнообразного контента, иначе игра не работает.
>У тебя скорее пикрил
Так ты хотя бы Симпсонов "убей". Там даже с такой "мультяшной" стилизацией дофига контента нужно. Сделаешь столько контента на целый город? Хорошо, разместим твой контент в чанках - будет опенворлд...
>Но да, ассетов надо больше
Да, да, идти, делай ассеты. Почему ты не делаешь?
>вертикальность чтобы кататься интересно было
Хорошо, умножай число ассетов, ты ж супер-разраб, создающий неограниченное количество ассетов за мгновение, пока ААА студии сливают 10 лет, имея огромные команды 3D моделлеров, а в результате получаются пустые и скучные открытые площадки.
>>1054202
Показывай свои гигабайты контента, раз тебе легко наделать ассеты на целый город, но сложно склеить получившиеся гигабайты в одну цельную площадку.
>>1054214
>То-то все открытые миры ТАКИЕ интересные.
>миры уровня "пустое поле - аванпост - пустое поле"
>Сколько РЕАЛЬНО интересных ОТКРЫТЫХ миров
Описанная тобой проблема возникает из-за того, что типичный игрок ожидает "интерактивное кино" на 4K мониторе, а для этого нужна высокая детализация контента (меши, текстуры). Создать гигантский мир с равномерной детализацией - значит, везде она будет минимальной. Поэтому делают маленькие кучки с повышенной детализацией и всё остальное - чисто наполнитель с очень низкой детализацией.
Другими словами:
- киношность требует много человеко-лет;
- большой мир умножает это на кв. километры.
Решение: делать набор из плотных кучек в пустыне.
Отдельно хочу заметить, что в дизайне уровней есть важное понятие "pacing": если ты сделаешь карту равномерной, то игроку это быстро наскучит. Нужно комбинировать моменты напряжённого геймплея с расслабленным, плотные кучи контента с пустыней. Контраст между разным игровым опытом важнее максимальной насыщенности этого опыта. Т.е. твоё передвижение по скучной пустыни подсознательно усиливает твой интерес к точке интереса в пустыне: расслабление чередуется с яркими впечатлениями.
>максимум сможет придумать одну механику
Дело не в механике. Мне лично всегда нравилось абсолютно бесцельно кататься по городу GTA как в симуляторе езды. Это одна механика. Мне лично не нравится стрельба, погони, гонки, миссии в ГТА. Но покататься по городу всё равно почему-то приятно.
Поэтому мне хотелось сделать "ГТА с процедурной генерацией городов", чтобы растянуть свой опыт бесцельной, но интересной езды до предела... Но на практике оказалось, что для генератора города тоже необходимо огромное количество контента, который придётся создавать полностью вручную. И меня это расстроило, я потерял интерес. Мне как-то совсем не интересно создавать тысячи домиков...
Ну, да, есть готовые паки ассетов, иногда они даже бесплатные. Но из одного пака большой город не получится... Нужно ещё больше контента. И он весь должен быть в одном едином стиле. А это просто огромное количество человеко-часов. Могу ли я вложиться в это? Могу. Хочу ли я? Да нет, не хочу...
Так что рассматривая идею "сделать ГТА", в первую очередь думайте о том, нравится ли вам делать 3D модельки домиков, деревьев, машин и прочего по 8 часов каждый день, 5 дней в неделю, несколько лет. Лично меня такая перспектива совсем не влечёт...
Нет, игрок ожидает интересного геймплея. Пустые и скучные открытые миры делали еще за долго до кинца и 4к мониторов
>Решение: делать набор из плотных кучек в пустыне.
Соло инди разработчик все равно не потянет. Это задача для больших команд.
>Т.е. твоё передвижение по скучной пустыни подсознательно усиливает твой интерес к точке интереса в пустыне: расслабление чередуется с яркими впечатлениями.
Круто, сколько таких точке должно быть на карте? 10? 100? 1000? Какая разница, если 90% из них окажутся копипастными аванпостами.
Идти по пустыне к точке интереса, когда тебя влечет делание раскрыть что-то интересное - это хорошо. Дерьмово, когда в точке назначения ты обнаруживаешь очередной аванпост
>Мне лично всегда нравилось абсолютно бесцельно кататься по городу GTA как в симуляторе езды.
Да, катиться по городу в закатное солнце под музыку из радио - это то, за что я люблю GTA Так то серия игр говно то еще. Но сколько это минут геймплея? Час? А дальше что? Дальше нужны остальные механики, которые бы работали в связке с покатушками на машине.
Да и бля, сделать нормальный симулятор вождения машины тоже та еще задача.
>Поэтому мне хотелось сделать "ГТА с процедурной генерацией городов"
Убьет тысячи человекочасов на бесцельный геймплей длиной в 1-2 часа. Зачем если можно просто поиграть в GTA 5? Накатить модов на карты и т.п.
>Так что рассматривая идею "сделать ГТА", в первую очередь думайте о том, нравится ли вам делать 3D модельки домиков, деревьев, машин и прочего по 8 часов каждый день, 5 дней в неделю, несколько лет. Лично меня такая перспектива совсем не влечёт...
Есть такая вещь, как "модульный дизайн". Сильно упрощает разработку
Дак речь шла о "проще" а не об "качественнее". Высрать поле с камнями и аванпостами рили проще. Разумеется проработанную линейную локу будет играть интереснее, но анон выше вроде не об этом писал. Да и гои хавают открытые миры только так.
>>1054216
Ахуеть, правда что ли?
Но я говорю о другой методике. Методике рандомно вьебать курсором по гугл картам и скопипастить участок ланшафта с поправкой на задуманный геймплей
>игрок ожидает интересного геймплея
Такие игроки играют в инди-игры, а не в ААА...
>Соло инди разработчик все равно не потянет
С кем ты споришь? Со мной ты соглашаешься?
>сколько таких точке должно быть на карте
>90% из них окажутся копипастными аванпостами
Не ко мне вопрос, я не СЕО ААА игровой компании.
>Но сколько это минут геймплея? Час?
>бесцельный геймплей длиной в 1-2 часа.
>Зачем если можно просто поиграть в GTA 5?
Больше 1000 часов убил на GTA Online: ты, видимо, не поверишь, но бОльшую часть я просто ездил. Там все миссии построены вокруг "доедь из А в Б и нажми X, чтобы выиграть 25k$, а потом повтори это 9999 раз". Идеальная структура геймплея, на мой взгляд - нет бессмысленного сюжета, зато много езды по городу.
>нормальный симулятор вождения машины
В серии GTA очень аркадное управление, что-то приблизительно похожее на VehicleBody в Godot. В четвёрке добавили реализма, в пятёрке его убрали. Конкретно в серии III/VC/SA машины примитивны...
>Дальше нужны остальные механики
По-твоему, их сложнее делать, чем контент?
>Есть такая вещь, как "модульный дизайн"
Покажи свою модульную игру, интересно. Я уже очень давно знаю про модульный дизайн, но всё, что он тебе даёт - это требование копипастить один ассет 999 раз. Разнообразия модульный дизайн точно не добавляет.
Или это я не выкупаю посткормление метатролля?
>"как мне сделать ГТА" - это троллинг
Ээээ, а если я реально хочу сделать инди-GTA-like? Реально ж есть инди-клоны GTA на той же юнити... Банально зайди в гугл-плей и поищи там "гта"/"gta"...
Ты так говоришь будто ТРЕТЬЯ ЖТА это что-то недостижимое. Сейчас индюки в одно ебло вполне тянут ААА проекты 90х годов. Обсудить это все дает понимание о возможностях и потенциальных ограничениях движка, и о подводных камнях самого проекта.
код третьей ГТА есть в открытом доступе, реверс-инжинирнутый
https://github.com/rocketguedes/re3
там и синглтоны есть (даже не классическим паттерном, а просто инстанс в глобальной переменной) и другие антипаттерны, кстати
>>1054245
перепиши всё это на гдскрипт
> и о подводных камнях самого проекта
ГТА, если припоминать, это игра с "миссиями", иначе говоря, миссии это такие данжи, которые активируются прямо на локациях, в них не надо входить, но они обладают всеми характеристиками данжей:
1. Данж это отдельный мир, не связанный с внешним опенворлдом.
2. Отдельные правила.
3. Скриптованный сценарий прохождения.
4. Награда в конце.
5. Выход обратно в опенворлд или в лобби.
>там и синглтоны есть и другие антипаттерны
Пиздец, она должна была провалиться. Почему она не провалилась?
>>1054176
без обратной связи никак
делаешь прототип и вкидываешь на двачь, и так раз 20-50-100
конечно, в каждой механике есть математическая модель, но она видна как результат анализа готовой механики, а не моделирование из абстрактных условий
не знаю, повезло
в первой ГТА даже мультиплеер был сделан глобальными переменными, PLAYER_1, ...PLAYER_8
вообще это нормально было для игр 90-ых
Потому что синглтоношиз тогда ещё не родился. И не насрал в списках рассылки разрабов ГТА.
Есть большо шанс что в синтаксисе говно-питона форматтер ошибется и всрёт логическую ошибку в каком-нибудь if...else (выкинув или засунув строку кода).
Почему нельзя было взять языки с ..{...}.. только дебилам известно.
Зачем тратить ресурс пальцев на {}$@#$)(*_!, когда можно не тратить? Да еще и глаза не ломать. Я вот даже вместо двойных кавычек предпочитаю одинарные, потому что шифт жать не надо.
Шарп - полноценный инстумент,
Гдскрипт - еще одно говно под ускую задачу, для дизайнеров.
Учить целый язык для еще одной микро задачи? Или же оттачивать скилл в шарпах и по желанию свичнуться в юнити или даже прикладную разработу (бэкенд?).
Да и в хозяйстве Шарфы очень полезны, у меня 100500 утилит на винформах. Не слушай дизайнеров, движок это тоже дерганье API - на каком языке его дергать без разницы.
Возможно получишь задержку на компиляцию - зато получишь полноценные типы, а не динамикодресню
Прислушайтесь к советам этого алкаша, алкобыдло пропитое хуйни не посоветует, хаха.
Ты анализировал всю статистику? Там профессиональных разработчиков очень мало, во основном вкатунцы и "потыкать".
Имхо, можно начинать на гдскрипт, а потом как будешь чувствовать себя комфортно в API движка, свичнутся на шарпы (или даже другой яп из расширений).
Сам гдскрипт - трата ресурсов мозга и времени.
>полноценные типы, а не динамикодресню
Ахах, да всем поебать на эту байтодрочь если ты не наносек пилящий три в ряд так чтобы они даже на тестах для беременности работали. Главное оружие шарпа это его домен и его кодоген, первое для createinstance, второе для всяких хитрых сериализаторов. Ну еще всякая мелочь типа триллион библиотек под что угодно, включая ml, ну то такое.
Чтобы потом нажать одну кнопку "формат" и все встало на своим места - не сломав ничего!
В питон синтаксисе это не достижимо.
Причем тут байтодрочерство, когда ты фундаментально знаешь что вернул очередной выпук в коде? Это банально удобство. Да, дизайнерам сложно, но что поделать.
Так в гдс обьекты формально обладают типом (который там хоть и для галочки, но всё же), так что видно будет.
>Учить целый язык
Ни нихуя ж себе! ЦЕЛЫЙ ЯЗЫК НАХУЙ! Уровня псевдокода. Епта, ты сейчас такой маркер дауна-дегенерата-ноускиллза выдал, что точно в яблочко. Языки, после того как ты опыт набрал, "учатся" на раз-два, ибо все похожи, за исключением может десятка низкоуровневых и/или экзотических типа лиспа-ерланга.
Пиздуй в свой загон, жалкое подпивасное неспособие.
> Учить целый язык для еще одной микро задачи?
Da.
>Такие игроки играют в инди-игры, а не в ААА
А мы тут что по твоему делаем?
>Больше 1000 часов убил на GTA Online: ты, видимо, не поверишь, но бОльшую часть я просто ездил
И что? О чем это по твоему говорит? Что все игроки будут с радостью ездить туда-сюда или о том, что ты просто аутист?
>В серии GTA очень аркадное управление
Ну запили. Где твой симулятор езды, епта? Это ж так легко
>чем контент
Путаешь причину и следствие. Механики порождают контент
>Разнообразия модульный дизайн точно не добавляет.
Омегалул
>А мы тут что по твоему делаем?
Я не знаю, что ты делаешь. Срёшь в треде?
>О чем это по твоему говорит?
О том, что на карте контента много - глаз радуется.
>все игроки будут с радостью ездить туда-сюда
А чем они, по-твоему, занимаются в GTA Online?
>Ну запили. Где твой симулятор езды, епта?
Я ещё весной 2020 заюзал VehicleBody, лол.
>Механики порождают контент
Да-да, контент сам материализуется.
>Омегалул
Покажи мне свои карты из 3.5 модулей.
>в юнити
Да-да, мы уже поняли откуда ты посерить залетел, можешь не пояснять.
Это тред годота, а не движкосрачей. Не думай что твое анальное недержание тебя оправдывает. Лови репорт и пиздуй в свой сральник ниже по доске.
>Ненужон.
Вся суть /gd - рисоваки пробуют себя в программной разработке.
>аррряяя я не проебал годы жизни на бесполезную хуиту, это вы жалкие рисоваки, а я успешный программизд, арррряяяя
Спешите видеть - залетный выпердыш очередного говновуза/курсов/галеры, который ваще не в курсе, как ковалась индустрия, пытается доказать, что для создания игр нужна некая мифическая база программирования. Своих игр он конечно не покажет.
Можешь взять свою профдеформацию, засунуть себе ее в жепу и съебаться обратно дрочить кавычки и закрывать спринты, или чем ты таким там невероятно полезным для геймдева, занимаешься
>Тупой фанбой, выбирай инструмент, а не религию.
Я и выбрал инструмент, который осиливается за полдня по официальным докам годота, похож на мои предыдущие инструменты, и не ебет мозг. Это ты тут про единственно расово верные языки™ задвигаешь и жонглируешь гнилыми доводами уровня "а что если в юнити перекатишься". А что если ТЫ перекатишься в программирование микроконтроллеров на форте, или под яббл на свифте, или на анрил где шарп язык не то что второго сорта, а десятого, ммм? Где там твои расово верные языки будут? Найдется инструмент удобней - я перекачусь на него, а ты так и будешь избегаторствовать и бояться всего нового, цепляясь за скиллы, со скриптом выученные 15 лет назад.
Летом 2024 были мои последние попытки в этом направлении, после чего я разочаровался в себе. Но концептуально катить по бесконечному ландшафту, обнаруживая забавные артефакты генерации, ммм... Приятные воспоминания, как будто ностальгия...
Что-то наподобие Minecraft, только без mine и craft. Раздражает, что Minecraft требует от тебя сидеть на фиксированном месте, наказывая за путешествия. Нафига игроку бесконечный игровой мир, если игра вынуждает сидеть дома, построенного над шахтой?
Похоже, я хочу GTA-like игру типа The Long Drive...
>программирование в геймдеве не нужно
Насколько тут все плохо.
>думаю вернуться к идее процедурной генерации
Думал-думал и передумал. Опять фигня будет...
>хвастается тем, что у него есть girlfriend
Отвратительно. Зачем ты это сюда принёс?
>>хвастается тем, что у него есть girlfriend
Но это же норма. Создатель стардювали жил на шее у бабы 5 лет, пока делал игру.
А я у мамки на шее сижу, пока игру делаю. Так нормально?
>Так нормально?
Я нашел плагин для годота, который добавляет поддержку битторента. На ГДСкрипте и плюсах. Держите, я знаю, вам тут это очень надо, без этого игры не делаются.
Хуле их там писать? Написал контроллер и всё, игра готова. Дальше только арт рисовать, модели моделить, диалоги составлять. Программирования 1%. Мы программисты свой процент сделали, и сидим, без игор.
И, ожидаемо, опять никакого сисярпа. Штож ты будешь делать.
Шарп не нужен.
Если хочешь оптимизировать код - переписывай гдскрипт на сишные модули. Если не хочешь пересобирать весь движок, пили их через гд-экстеншон. Сисярп точно так же через гд-экстеншон подключён (под своим капотом) только привязывает твой конечный продукт к дотнету. Ты уже выучил сисярп, остался ещё один небольшой шажочек, чтобы выучить кресты и стать богом этого мира, уаахаха!
>один небольшой шажочек, чтобы выучить кресты
Лол, мне страшно представить всю ту жопоболь, который испытает шарповик, переходя на кресты. У диеза с гдскриптом больше общего.
Я щас Go изучаю - вот это риальне гдскрипт для системы, который я искал.
В этом говне больше подводных чем в жопоскрипте.
Его терпят только из-за асинхронной природы в микросервисах (где вообще пофиг на чем писать, но тут хоть типизация хоть какая-то есть).
Но в любом случае это полноценный язык, в отличие от квази-скриптов.
Это обман, посмотри болеее реальные проекты, там чёрт ногу сломит. Если тебе нужен питон - бери питон.
Считается, джемовые игры иногда взлетают. Реально 1 загрузка? Или ты под веб делал?
>>1054779
По крайней мере я научился квадратный корень считать (а заодно и любые корни) уже время не зря потрачено.
>Реально 1 загрузка? Или ты под веб делал?
Под веб. Пикрил просто чтобы поприбедняться. Хотя, в браузере тоже никто не играет мои игры лол. Я баловался, серьезные игры я ещё не доделывал. Ну я и в геймдеве всего полгода-год. А вот когда доделаю свой основной проект...
Чем больше так делаешь, тем больше себе замедляешь работу в будущем. Если ты делаешь что-то серьезнее змейки или кликера, то это путь в могилу. Потом офигеешь переписывать все на export/ресурсы/наследники
Как именно я прокладываю путь в могилу? Пока выглядит наоборот, выкапываюсь из под слоя лишней работы.
>я ленюсь делать
>это и есть верный путь?
Да, это верный путь дзен-геймдева:
1. Ленишься в кроватке до вечера.
2. В полночь открываешь Godot.
3. Созерцаешь пустую сцену.
4. Медитативно урчишь.
5. Выключаешь ПК.
6. Засыпаешь.
7. [удалено]
8. Нирвана.
>Editable Children
Рака сцен захотелось?..
>>1054871
>Как именно я прокладываю путь
Ты же сам писал, как это делаешь:
>рукой в редакторе меняю свойства
Забыл уже? Боюсь, тебя не спасти...
>Ты же сам писал, как это делаешь:
Да, и это быстрее чем городить геттеры-сеттеры. Какие подводные то? Конкретно. Пока ИТТ от любителей сеттеров ничего кроме туманных угроз апокалипсиса, тогда как с editable children сразу тепло и приятно.
>Какие подводные то? Конкретно.
Иди подучи ООП. Конкретно тему инкапсуляции:
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)
https://stackoverflow.com/questions/18300953/why-encapsulation-is-an-important-feature-of-oop-languages
Ну, ладно, разберу конкретно в контексте Godot...
Для чего в Godot может понадобиться сохранять группу нод в качестве отдельного файла-сцены (tscn)?
1. Декомпозиция. Ты разделяешь одну сложную сцену на несколько простых, но уникальных частей, которые включаются внутрь основной сцены один раз и больше нигде не используются. Чтобы отредактировать часть сложной сцены, ты открываешь отдельный файл и правишь его. Поскольку это уникальные части одной уникальной сцены, они могут быть взаимосвязаны друг с другом как угодно.
2. Повторное использование. Ты создаёшь сцену как компонент для многократного использования внутри произвольных других сцен. У этого компонента есть какое-то внутреннее поведение и внешнее поведение. Сцены, использующие эту сцену-компонент полагаются в первую очередь на внешнее поведение, то есть ты абстрагируешь какую-то внутреннюю функциональность компонента от внешних сцен.
В чём проблема использовать "Editable Children" в этих ситуациях?
1. В случае декомпозиции, ты выделил маленькую сцену из большой, чтобы позволить себе сфокусироваться на конкретных деталях этой маленькой сцены. Тебе должно быть банально проще открыть файл сцены и изменить настройки внутри него, чем вносить правки во внешней большой сцене через "Editable Children". Если же ты всё-таки зачем-то внёс эти правки, теперь у тебя данные маленькой сцены разбросаны в двух местах - в самом файле маленькой сцены и в файле большой сцены, так что можно потом запутаться, что и где применяется. Если ты захочешь временно исключить маленькую сцену из большой, данные в большой сцене потеряются (не надо начинать про git, бэкапы и т.д., т.к. любой откат проекта - это всегда впустую потраченное время), если ты не сделаешь отдельную копию большой сцены для экспериментов. Но в целом ты можешь использовать любой подход в этом случае, т.к. ущерб для проекта будет минимальный и локализованный.
2. В случае повторного использования, у тебя есть один файл сцены с внутренним поведением и десятки, сотни или даже тысячи мест в других сценах проекта, где эта сцена как-то используется. Все эти сцены полагаются на поведение этой сцены-компонента, верно? Но по умолчанию они полагаются только внешнее поведение: свойства, методы и сигналы корневой ноды. Внешние сцены "не знают", что находится внутри, под корневой нодой, пока ты не нажмёшь "Editable Children" (на самом деле, из кода ты можешь достать до любой ноды, если знаешь путь; эта кнопка даёт доступ пользователю через GUI и позволяет сохранить изменения в файл). Если ты начинаешь активно использовать "Editable Children" в разных местах проекта, то когда по какой-либо причине тебе придётся внести правки внутрь сцены-компонента, это сломает твой проект сразу во множестве мест, в худшем случае - во всех местах, где использовалась изменённая сцена-компонент.
Для примера, рассмотрим особую мультиплеерную кнопку с полем ввода:
>EditableButton: Control
>_ Picture: TextureRect
>_ Input: LineEdit
>_ Send: Button
Ты использовал эту сцену-кнопку во многих UI-сценах, а потом:
- изменил имя любой из внутренних нод (Picture -> Background, Send -> OK, Input -> Field);
- поменял порядок/расположение нод (LineEdit и Button стали потомками TextureRect);
- изменил класс любой из нод на какой-то другой (решил отказаться от Button -> Control);
- удалил какую-либо ноду совсем (удалил TextureRect -> картинку стал рисовать в _draw());
- добавил ноду, повторяющую значение другой (Title: Label.text копирует LineEdit.text);
- существенно изменил внутреннее поведение (картинка теперь изменяется по клику).
С высокой вероятностью часть или даже все UI-сцены с этой сценой-кнопкой сломаются.
Т.е. тебе придётся вносить правки во всех местах, где было нажато "Editable Children".
Типичные возражения на описанную проблему (уже обсуждали в прошлых тредах):
>Сделай один раз компонент и больше не трогай его, зачем что-то менять?
>Сделай игру за 1 час/день/неделю/месяц и всё, а следующую делай с нуля.
Эти аргументы не учитывают то, что в разработке игр, да и любого программного продукта, требования могут измениться на полпути до релиза, и придётся переделать то, что работало безошибочно и казалось, что трогать не придётся. А иногда обнаруживаются "спящие" баги, которые долго скрываются в казалось бы безошибочном компоненте, пока не используешь его в 100 разных местах проекта. Иногда приходится заниматься оптимизацией, вырезая из безошибочно работающего компонента лишнюю деталь. Иногда задумка просто оказывается тупой и приходится делать шаг назад, когда уже убежал далеко вперёд. А за месяц можно сделать только совсем уж примитивные игрушки, чаще всего - из готовых компонентов, которые далеки до реально прибыльных инди-игр, добившихся успеха. Более того, даже в примитивных игрушках-одноневках использование старых компонентов выгоднее написания всего с нуля, а иметь десятки версий одного компонента в десятке игр не очень удобно. Поэтому эти аргументы уровня "мне норм, значит и всем остальным будет норм" от тех, кто не пытался делать достаточно сложные игры или использовать результаты своих же трудов в своих новых играх.
С уважением,
синглтоношиз
Это всё не для игровых обьектов, а для интерфейсов в первую очередь делалось. Сделал элемент интерфейса - можно им везде срать, только стили меняй у чилд обьектов по требованию. В игровой логике - да, могут быть ньюансы.
Ок, я запомню эти подводные и не наткнусь на них, но по-прежнему буду editable children. Проблема решена, спасибо за объяснения.
> ai midi generator
На этом этапе мне предложили залогиниться, а я анонимус, имя мне - легион. Так что не работает твой план.
Их есмь у меня
Потому что она отрицает синглтон и все ресурсы её организма выделяются по нескольку раз и уничтожаются после использования, вместо того, чтобы сидеть в оперативке весь жизненный цикл в одном экземпляре.
Покатились
>>1055144 (OP)
>>1055144 (OP)
>>1055144 (OP)