Токсим, срёмся, диагностируем шизофрению и объявляем крысу в хате тоже здесь.
Бесконечный тред для свободного общения.
>Смотря какую игру
>симулятор всяких трехсторонних порталов
Так игру или симулятор порталов?
>4д
Очень сложно для восприятия игроком, кроме как для моделирования всяких красивых сценок на ютабчике - не нужно. Да и для этого не надо писать никакие рендеры на расте, есть вагон симуляционных либ под питон с графикой, хоть обмоделируйся, какие угодно мерные пространства, неэвклидовая геометрия и прочее. Неэвклид кстати отлично эмулируется в юнити, есть тестовые проекты. Но дело как обычно, не в геометрии, не в трехсторонних порталах, а в геймплее.
>если бы воевал с юнити
Война с юнити будет всегда, даже когда ты будешь писать шутер. Другое дело, что эта война оправдана, т.к. победив движок в ряде ключевых аспектов - другие ключевые аспекты (редактор, кроссплатформу, встроенные оптимизации, рендер) ты получаешь бесплатно. Все в конечном итоге сводится к одному - или победи движок по небольшому списку аспектов и получи игру - или сиди вечно безигорным, дрочащим прототип на пропердывающем рендере, зато с поддержкой трехсторонних порталалов
Открываем а там кресты и полрендера переписано
Она не оправдана потому что ты скорее всего никогда ее не сможешь победить и встроить то что тебе нужно не поломав остальное,, поэтому ты будешь сидеть без игры, поскольку не релиазуешь ключевую идею, как трехсторонние порталы, и все эти системы загрузки и редакторы тебе окажутся не нужны. А так все тобой указанное можно проще набрать либами с нуля, чем отковыривать все от юнити.
Выбери анрил или годот и встрой в рендер все что тебе нужно, хз в чем проблема. Хоть пятисторонние порталы.
И что? Кто-то запрещает писать на плюсах на годоте и переписывать все, что хочется из исходников?
Кто-то на законодательном уровне закрепил, что ты либо бздотя, либо таскаешь ассеты мышкой?
>ты либо бздотя, либо таскаешь ассеты мышкой
Подростковый максимализм, сам понимаешь...
а, надо просто все переписать из исходников годот. и как я сразу не догадался, что это так просто...
ты какой-то неадекватный.
учиться в школе/университете это тоже подростковый масимализм.
взрослые просто однажды просыпаются, и, как нео, знаю кунг-фу. это так и работает.
Не надо, а можно при желании и необходимости. Не виляй сракой, клоун.
Кунг фу это как раз мастерское владение готовым движком.
Путь бздоти - это бесконтактный бой из мемов, где пузатый мужик приседает, и его помощники вокруг него делают вид, что разлетаются от невидимых ударов
>клоун, который c++ в глаза не видел, а о графическом программировании даже не слышал, фантазирует как он перепишет годот при необходимости
как твой диагноз твоей в справке от психиатра называется
Я делаю игру на анриле, пишу на с++, блюпринты по минимуму. На плюсах еще под первый анрил писал моды в нулевых.
А вот ты похож на клоуна, который никогда не прикасался к движку и считает это невероятно сложной магией, и поэтому пытается компенсировать пропукиванием цветных треугольников через сдл
то есть у тебя 20 лет опыта, и ты их проецируешь на остальных?
ну, допустим делал моды, это еще не значит что ты знаешь графическое программирование. а разбираться в низкокаественном помойке кода годот это еще 10x сложнее, чем сделать самому.
Понимать код не для него, уметь в отладку не для него. Курить мануалы сутками это ужасно. И более того когда он берет за базу чужой код он банально игнорирует контекст требования, и наложенные ограничения. При этом что на выходе? Сомнительные умения и нулевой рост.
А нам пользователям приходится разбираться в монструозных надмозговых решениях выжирающие наше время и ресурсы. А главное выступишь с критикой получишь гигантский поток необоснованного снобизма.
P.S. самый важный и ключевой в мире код пишется без гитхаба.
P.P.S я как не программист но имеющий потребности в приложениях уж лучше отдам работу джуна какому-нибудь ИИ, он все равно сделает быстрее и без потока снобизма и бесплатно.
У тебя NIH-синдром в терминальной стадии.
https://en.wikipedia.org/wiki/Not_invented_here
Зачем изобретать колёса для твоего самодельного велосипеда? Зачем изобреть покрышки для колёс велосипеда? Если тебя интересует руль и сиденье комфортной формы и размера под твою огромную задницу и кривые короткие ручки, то тебе не только колёса изобретать не нужно, но и цепь с педалями и шестерёнками. Можешь просто готовый велосипед приобрести и поменять руль с сиденьем под себя. Можешь сварить из покупных труб раму, поставить готовые колёса, педали и цепь, а потом уже на это - нестандартный руль и сиденье. Но не нужно сидеть изобретать колесо, когда тебе и готовое подойдёт.
И даже если лично тебе нравится изобретать самому методику вулканизации резины для покрышек, лить стальные трубы из расплавленного металла и т.д., большинству людей это вообще не нужно. Что нужно большинству - так это взять велосипед и поехать в направлении точки назначения, и доехать целыми и здоровыми. Некоторым некомфортно с базовыми сиденьями и рулями - меняют на свои. Но не сидят в гараже месяцами, изобретая свой велосипед с нуля.
>Нашел репозиторий, скопирнул и доволен
>ИИ, он все равно сделает быстрее
Так он же ведь тоже "копирует"...
> Она не оправдана потому что ты скорее всего
> скорее всего
Сотни тысяч релизнутых игр говорят об обратном.
И плеебл адс работающие в рекламе на телефоне(!), и инди от соло разрабов и небольших команд, и ААА над которыми работают сотни человек. У всех почему-то получается, хотя ты говоришь скорее всего не должно.
> Курить мануалы сутками это
время
> P.P.S я как не программист
не имеешь никакого предстааления о том как происходит разработка ПО в целом и игр в частности
> самый важный и ключевой в мире код пишется без гитхаба.
Кек
но ведь мне не первому пришла в голову столь гениальная идея, наверняка кто-то уже это делает
Отсутствует экономическая выгода.
По фану - слишком долго и результат хз.
просто движок, победивший за счет оголтелого маркетинга. это печально, потому что демонстрирует что маркетинг решает не только в играх, но даже в движках, где, казалось бы, должна быть объективность.
Инвалидов победить любой может, вот если бы ты сделал лучше анрила или викед энжина, было бы интересно.
Не, мне больше нравится другая метафора, годот - это цветущий город-сад, который прекрасен и удобен для жизни, поскольку построен самими людьми, его населяюшими.
>объективность
Расскажи какой еще foss движок обьективно обладает аналогичным набором характеристик, кои присущи годоту - кроссплатформа, поддержка разных языков, редактор, 2д, 3д, 3 бэкенда рендеринга (vk, dX, gles), модульность вплоть до возможности написать свой рендер и свою физику? Только давай без клоунских проходов в "нинужна".
>кроссплатформа
практически любой движок
>поддержка разных языков
нет никакой поддержки. васяны там что-то делают на стороне, но с таким же успехом можно добавить "поддержку" к любому движку
>редактор
примитивный, бесполезный редактор сцены (без play mode), в котором до недавнего времени не было даже ID ресурсов.
>vk, dX, gles
это не является преимуществом. вообще, ничего из этого не является преимуществом. фреймворк движка отвратительный, API неудобное. редактор до безобразия любительский, примитивный.
я же говорю, тебе только кажется что в годот все хорошо, потому что у тебя нет опыта.
скачай, например, демку https://store.steampowered.com/app/251810/Leadwerks_Game_Engine_5/ и поиграйся пару дней.
Анончик, мы тут не первый год сидим и уже перепробовали все опен сорс движки. Как только появится что-то лучше годота, я первый же перейду. Но таких нет и не предвидится.
>практически любой движок
Какой? Езенгине винда онли, дефолд - 2д онли, викед - тоже винда онли. Так какой?
>нет никакой поддержки
Забавное отрицание реальности, ведь у движка нет модулей на расте или с++, или поддержки дотнета
>примитивный, бесполезный редактор сцены
Так где не примитивный? И со всеми вышеперечисленными возможностями?
>в котором до недавнего времени не было даже ID ресурсов
Id появились два года назад, держу в курсе. Впрочем я их все равно не юзаю, привык к путям и полюбил их.
>это не является преимуществом. вообще, ничего из этого не является преимуществом == ряяя нинужно я скозал
>редактор до безобразия любительский, примитивный.
>https://store.steampowered.com/app/251810/Leadwerks_Game_Engine_5/
>На видосе интерфейс годот 1
Ты бы хоть викед кинул, чтобы не так смешно было, ну или open3d.
>практически любой движок
Пиздеж. Ты сам даешь ссылку на leadwerks где
>in 2014 mobile support removed
Да и веба там незаметно. Ну это не говоря про нинтенду свитч и так далее.
>нет никакой поддержки
Пиздеж. Из коробки: C/C++, C#
>(без play mode)
Нинужно, это бесполезная концепция для юнитидетей
впрочем, ее для них уже добавили.
Так что опять пиздеж
>не было даже ID ресурсов.
Нинужно, как без них выпускал игры, так и сейчас ни разу не понадобилось ими пользоваться.
>API неудобное
Единственное с чем можно согласиться 50/50, Бывает изредка, какой то параметр не проброшен ну так опенсорс, все решается.
>примитивный редактор
расширяется tool скриптами под задачу.
я говорю о реальных преимуществах опыта использования движка, типа хорошего фреймворка, или play mode, являющегося незаменимым решением для быстро прототипирования и отладки, а ты рассказываешь о какой-то ерунде вроде платформ. это как покупать грузовик для езды по городу, а то вдруг раз в 10 лет тебе понадобится поехать на дачу. такая же логика.
у платформ свои особенности, особенно у мобильных и веб. движок, работающих на всех платформах, работает на всех платформах одинаково плохо. реализация платформ для галки это просто маркетинговая уловка, чтобы побольше логотипов на главной странице нарисовать. новичкам это нравится. никакие из этих платформ им никогда не будут нужны, разумеется.
ты просто новичок очарованный маркетинговой шелухой, не способный принимать рациональные решения.
>для них уже добавили
добавили возможность выбрать мышкой объект в игровом окне, чтобы для галки написать "у нас есть play mode дома"?
>так и сейчас ни разу не понадобилось ими пользоваться
это потому что ты ничего не делаешь на годот, только фантазируешь как твоя игра выйдет на всех платформах одновременно. сломать проект из-за строковых путей - элементарное дело.
>ну так опенсорс, все решается
ой, как удобно. когда в ezEngine нет платформы, то это проблема ezEngine, а когда в godot чего нет, то это решается и вообще опен сорс.
если бы ezEngine зарабатывал миллион в год, там бы тоже были все платформы какие только захочешь.
Но ведь действительно, то что езижин не зарабатывает лям в год это проблема эзинжин, а не годота..
Это надуманная проблема, только если у тебя какой то ОКР и ты все двигаешь вверх вниз по иерархии, у меня ни в одном проекте таких проблем не вознкало, кроме каких-то самых первых при обучении, потому что всегда заранее понятна вертикальная архитектура, а там уже доступ к объектам обычно через пулы или массивчики, или банально get_children
А истерика по повододу миллиона в год тоже смешна, миллион чего, рублей (и по курсу какого года)? Так это ниачем, особенно при том что делилось на несколько человек, если ты имеешь в виду доллары, так такого не было на протяжении большинства лет, там были копейки, по сути Хуан написал базу и мясцо движка миллион строк кода за бесплатно и подарил всем. Никто не мешал то же самое делать любому другому.
>типа хорошего фреймворка
Нормальный фреймворк
>play mode, являющегося незаменимым решением для быстро прототипирования и отладки
Добавлен уже давно
>а ты рассказываешь о какой-то ерунде вроде платформ.
Опять нинужно
>движок, работающих на всех платформах, работает на всех платформах одинаково плохо.
Юнити например отлично работает на всех платформах, а годот - фосс, с него меньше требования (и он тоже +- нормально работает на заявленных платформах, не без ньюансов, но аналогов нет).
>никакие из этих платформ им никогда не будут нужны, разумеется.
Ты скозал?
>рациональные решения.
В таком вопросе как разработка игр рациональность решения диктует слишком много факторов, в которых производительность перекладывания байтов или наличие плеймода может оказаться даже не в первой десятке этих самых факторов. А вот все что я обозначил выше - может оказаться гораздо важнее.
>у нас есть play mode дома
А минусы? Минусы будут?
а что изменилось?
разработка идёт потихоньку
движок опенсорсный, что-то хочешь изменить - подключайся
пулл-реквесты принимаются
>Разработка идет
>https://github.com/NauEngine/NauEnginePublic/pull/44/commits/676704ebdea2ce94a29be37d163a7d78179d653c
>коммит в 20 строчек за 4 месяца
Ждем обновление ридми через полгода
>пулл-реквесты принимаются
Куда? В ликвидированный движок, в который мерджит функционал даже не смотря что туда всунули какой-нибудь аспирант за 3 рубля?
Помню и до сих пор бомбит., потому что могли же сделать хорошо, там реально было какое-то ядро команды с прямыми руками.
> 20 строчек за 4 месяца
так это опенсорс, если не устраивает, коммить больше сам
>это опенсорс
Это не опенсорс, это памятник распилу газпрома
это серьёзное обвинение
у нас за это жёстко спрашивают - вплоть до пожизненного
покажи кто что "распилил". ведь у тебя есть все доказательства, так?
нет, я так и думал
Так ты и есть ньюфаг рассуждающий как ньюфаг, ничего серьезного ты плеймодом отладить не сможешь, вот делаешь ты платформер/шутер с ботами/стратегию, передвинул препятствие камушек во время игры, и все, тебе все равно надо перезапускать уровень, потому что теперь тайминги другие, пасфайндинг будет другой и т.д. То же самое и с изкоробочным редактором, он вообще не всем играм нужен, в некоторых играх вообще все генерится, в других нужен свой кастомный редактор. Ты буквально как обезъянка увидел вещи ориентированные на ньюфагов в движках G и X и побежал копировать не понимая сути.
>у нас за это жёстко спрашивают - вплоть до пожизненного
А у тех, кто показывает доказательства - еще и вплоть до прижизненного
Я люблю ezengine, движок с большим потенциалом, он мог бы быть лучше годота, и даже сейчас лучше в каких-то моментах, но в таком формате разработки у него нет будущего, к сожалению. Его пилит пара энтузиастов в свободное от работы время, темпы разработки очень низкие. Они не заинтересованы в создании коммьюнити, привлечении донатов, новых контрибьюторов, не занимаются маркетингом. Пока эта позиция не изменится, у движка нет шансов выстрелить как у годота
Надо было просто сразу делать открытый опенсорс. А не закрытый с "раз в год выкладываем билд", до второго уже и не дожили.
>такого не было на протяжении большинства лет
годот с самого начала получал десятки тысяч в месяц плюс были всякие сомнительные спонсоры, лого которых даже показывали каждый раз при запуске наравне с синим роботом.
когда годот делал один хуан, это было полное дерьмо с функционалом меньше ezEngine (оно и сейчас дерьмо, просто наряженная свинья с нескучной темой и кучей пустых обещаний и функций реализованных для галки, просто 99% пользователей дальше базовых функций никогда не лезет).
>>1084677
>он тоже +- нормально работает на заявленных платформа
годот даже на windows не работает нормально и имеет 10к багов. а что там на android с зоопарком китайских телефонов даже страшно представить, просто нет сумасшедших это проверять.
>>1084707
ты напоминаешь программистов, которые пишут на C в emacs, используют printf для отладки и им все нормально. неандерталец с каменным топором. я же говорю, просто попользуйся ezEngine несколько дней, после этого годот будет вызывать у тебя физическое чувство тошноты.
>наличие плеймода может оказаться даже не в первой десятке этих самых факторов
ну и в чем рациональное решение использовать годот для slay the spire? что, у них основные продажи на андроиде? или может у road to vostok есть веб сборка?
годотные придурки сделали функцию, которая возвращает тип отличный от того, который ожидается в C# коде, из-за чего сломался вызов функций. какой то дурачок провел бесплатно целое расследование.
сколько еще таких мин заложено под годот некомпетентными разработчиками, на которые вы нарветесь во время разработки.
это особенно актуально в контексте разных платформ, о которых фантазируют безыгорники.
на windows все у всех работало, а на linux вдруг перестало работать.
так и у тебя будет, когда в конце разработки вдруг окажется что твоя андроид сборка вся дырявая и не работает.
Не пользуйся c# унитиребенок, когда божественный гдскрипт
я уже написал что проект открытый
так что кто виноват запоздании фич? лично ты! потому что не хочешь разрабатывать
капец, я вчера узнал, что в годоти всё основано на динамическом типе Variant
возможно это один из главных источников пропуков. там всё надо переписывать с нуля
кек
1 анимация проигрывается 1 миллисекунду!
они C# быстро приделали поверх gdscript, чтобы поставить галочку "C#: done!"
не защищаю годот, но в юнити тоже встроенный компонент animator тормозной, но не настолько
забытые технологии предков, во флэше всё работало на pentium 266 с 64 мБ ОЗУ
>годот с самого начала получал десятки тысяч в месяц
Про годот до его третьей версии вообще знали единицы, только где-то на тройке народ стал его замечать, так что ты пиздишь
>когда годот делал один хуан, это было полное дерьмо
Ну да. Любое ПО проходит через стадию полного дерьма. Но после всех переписываний, от годота 1 в тройке и четверке остался только синий интерфейс, факт существования гдс и всё.
>годот даже на windows не работает нормально и имеет 10к багов
Любое ПО имеет баги. Даже твой любимый ezengine. Даже юнити имеет баги. Но у годота и юнити есть сообщество, которое находит баги и их исправляют. А у езенгине есть только молящиеся на него безигорники, которые даже не пытаются делать на нем хоть что-то. Вот у него и "нет багов".
> что там на android с зоопарком китайских телефонов даже страшно представить, просто нет сумасшедших это проверять.
Бротато проверил. Там все заебись. Можешь влетать в годот.
>>1084717
>ну и в чем рациональное решение использовать годот для slay the spire? что, у них основные продажи на андроиде? или может у road to vostok есть веб сборка?
Есть бротато, вышел на куче платформ. Я делаю 3д веб игрушку, для меня веб важен. А конкретно sts2 и RtV - это отголоски runtime fee юнити. Не все разрабы затерпели эту хуйню.
https://github.com/godotengine/godot/issues/115960
>Любое ПО имеет баги
баг - это ошибка. в годот не случайные ошибки, а систематическое низкое качество кода ведущее к катастрофическим лавинообразным последствиями. это совершенно другой класс проблем. называть это "багами" - это кривить душой.
>катастрофическим лавинообразным последствиями
Единственные катастрафически лавинообразные последствия которые я наблюдаю - это последствия для бздотя-энжинов (они умирают). Другой катастрофы не наблюдается. Зато наблюдаются успешные релизы игр, как 2д так и 3д, к тому же на мультиплатформе.
выпускать игры можно на чем угодно, особенно если уже есть опыт создания такой же игры на своем движке. это то, о чем новички забывают.
возвращаясь к тому, что я ранее написал, годот - это плохой движок ставший популярным только благодаря агрессивному маркетингу. можно делать игры и на плохих движках. но никто не станет отрицать, что делать игры на хороших движках лучше, чем на плохих.
>особенно если уже есть опыт создания такой же игры на своем движке
Этого опыта нет у 99.9% бздотей. Один из идеальных примеров - ezengine (впрочем викед тоже можно назвать безигорным). Хуан хотябы три в ряд пилил на том что представляло собой годот до его публикации в гитхабе. Возможно именно это и послужило причиной, по которой эти движки сосут на фоне годота. Годот всегда готов к тому что на нем будут делать игру. А бздотя движки - готовы только к демкам.
>годот - это плохой движок ставший популярным только благодаря агрессивному маркетингу
Вечно бздотям кто-то говно в штаны подбрасывает, то нарот геймдевский не тот, то агрессивный маркетинг (в последнее время - преимущественно маркетинг игровыми релизами).
>но никто не станет отрицать, что делать игры на хороших движках лучше, чем на плохих.
Критерии хорошести и плохости у каждого разные, при чем эти критерии являются кумулятивными и учитывающимися системно для каждого отдельного движка.
ничего хуан не пилил, не надо врать
он никогда не делал игры, только моделировал какой-то ролик про инопланетян в 1996 году, если правильно помню
примеры на ezengine в 100 раз лучше любой игры хуана
>ничего хуан не пилил, не надо врать
Он был учредителем нескольких игровых компаний еще до релиза годот, так что пиздишь тут только ты
да, известная схема, у нас называется "дроп"
находят бомжа с паспортом и за бутылку делают учредителем
а тебе какое дело до чужих игровых релизов? ты действуешь не рационально, как фанатик, радуешься чужим победам, вместо того, чтобы думать о своих. о чем я и говорил, ты под влиянием агрессивной рекламы.
1 миллисекунда на обработку одной анимации, или 300 пустых с пустым скриптов убивающие FPS в 2 раза - это хороший или плохой критерий?
долбарики из годот сделали API которое срет объектами с finalizer'ами(!) по любому поводу, из-за этого у пользователся годот один вызов метода в коде приводит к 20 мс(!!!) паузам.
интересно, он все еще рад, что решил делать игру на годот, как местные безыгорки, или уже не очень
>а тебе какое дело до чужих игровых релизов?
Это наглядные примеры успеха. Люди рискнули, вложили ресурсы, распостранились на большое количество компов и у них все хорошо. Это как говорися "реальный кейс", а не маняаргументы в стиле "пук среньк фреймворк лучше©™ код чище"
>ты под влиянием агрессивной рекламы.
Мировосприятие бздоти би лайк - "мое колесо самое лучшее, а колесо у остальных хуже, потому что оно не мое и я не знаю почему там 8 спиц а не 6 как у меня, они просто под влиянием агрессивной рекламы"
>>1084758
>это хороший или плохой критерий
Сам факт того что шарп поддерживают три калеки, что порождает подобные проблемы - может быть плохим критерием. Просто нужно держать в уме, что шарп поддерживают три калеки, а значит имеет смысл писать синтетику. Я например - даже на юнити писал синтетику, чтобы понять что движок потянет - а что нет. В век ии - написать синтетику это минута дела, которая может сэкономить в итоге недели и месяцы работы. При работе с годотом - мне приходолось достаточно помногу лавировать между его подводными, но я так и не столкнулся с нерешаемой проблемой. Ну и сам фактор "пустых скриптов" - не фактор ни разу, то что срать нодами/скриптами в больших обьемах плохая идея - известно еще с юнити.
А ведь могли бы оставить моно и таких проблем бы не было...
мимо троешник с моно ехидно хихикающий с дотнет терпил
то, что создатели slay the spire сделали игру на своем движке и потом с имеющемся опытом сделали игру на годот, лично к тебе не имеет никакого отношения. это просто эмоциональный, стадный отклик фанатика "они такие же как я". нет, они не такие.
>у них все хоро...
https://steamcommunity.com/app/1963610/discussions/0/603043051218226213/
>having same thing on my amd
>its unplayable
я тебе привожу реальные "кейсы" из issues. может пойти сам почитать. там таких "реальных кейсов" полно.
ну ты конечно можешь радоваться за чужую 2D игру, которая рисует аж рисует спрайты без сильных проблем.
Речь в посте о демке двухлетней давности
Хз, у меня никакими заиканиями не пахнет даже. А все потому что дело в gc. Именно поэтому юнити использует моно а не дотнет.
>я тебе привожу реальные "кейсы" из issues. может пойти сам почитать. там таких "реальных кейсов" полно.
Кейсы чего? Багов? Они везде есть.
>ну ты конечно можешь радоваться за чужую 2D игру, которая рисует аж рисует спрайты без сильных проблем.
Твоя аргументация про 2д сильно устарела, у нас есть восток, которому 10к ишьюсов ну никак не мешает стабильно работать
во первых, не известен уровень экспертизы разработчиков востока. во вторых, неизвестно какой процент движка они переписали, может это форк движка, в котором все свое.
повторяю, что радоваться чужим играм это просто не рациональный фанатизм, и проекция. у тебя так же не получится, у тебя получится как у бедолаг из issues, которые просто скачали движок, просто вызывают функции, о которых они прочитали в документации и просто получают пропуки по 50мс на пустой сцене.
>во первых, не известен уровень экспертизы разработчиков востока.
Как экспертиза влияет на движок и его исполнение? Аура экспертизы делает из неработающего (по твоим словам) движка - хорошо работающий у игроков движок? Или может все таки движок работающий, просто не без ньюансов?
>во вторых, неизвестно какой процент движка они переписали
Процент известный - 0%. Игра после распаковки спокойно открывается в редакторе годота.
https://www.reddit.com/r/godot/comments/1sig3mh/opened_up_road_to_vostok_in_the_editor/
>у тебя так же не получится
У меня получается все что мне надо, правда на тройке. Но на четверке, я думаю, тоже получится без особенных проблем.
>годот с самого начала получал десятки тысяч в месяц, мутные спонсоры
Так это уже 3-я версия, и изначально они получали дай бог тыщ 3 + 1.5 от спонсора и это только к началу 2018 года, а движок в опенсорсе с 2014. Там конечо был еще разовый грант о мозиллы на 20к на вебсокеты, но ты уж вообще выдумываешь про десятки тыщ в месяц. Там буквально обычная зарплата программиста была не более
>когда годот делал один хуан, это было полное дерьмо с функционалом меньше ezEngine
Можно скачать 2-ю версию и какую-то из первых и там уже все было заложено.
https://www.youtube.com/watch?v=zs_heJ6jzaE
Поправка - у тебя не получится. У меня все получается лучше, а ишью бедолаг я иногда чиню и отправляю фиксы. Ты тоже мог бы, например сделать крутой аддон для редактора раз у тебя такие крутые гизмы, но ты выбрал путь обиженки.
Опять пиздеж. Игра на предшественнике годота - футбольная мобилка 2013 года.
https://www.youtube.com/watch?v=38rdOWC-6es
да, опять ложь с твоей стороны
хуан сам признавался, что не сделал ни одной игры. он не разработчик игр, а разработчик движков
Во-первых, давай ссылочку. Во-вторых, все верно, он был программистом движка в этой игре, это часть разработки игры.
По-моему, у разработчика востока - слишком высокие запросы для годота. Не тот движок выбрал для такой игры.
То, что он планирует сделать, да ещё и в таком сетиинге, он мог бы лет 5-6 делать и доделать на анриле каком-нибудь условно.
Но, гои прогрелись, и будут удивлены, когда через лет 5 - рам все также нихуя не поменяется особо.
Это распространенное заблуждение, что годот якобы не подходит для такой игры. Как раз приятно, что он это развенчивает.
Да какая разница что он выбрал. Игра есть, игра выглядит хорошо (хоть и видно что инди). Сам выход подобной игры - победа foss. Мылогенератор 5 конечно потехнологичнее будет, но это личный выбор каждого, делать игру на своем движке или на движке дяди.
>победа foss
опять бесмысленный фанатизм. это победа только разработчиков игры, которые сменили движок на фоне горячей темы, чтобы рекламироваться в околоигровых сообществах, и это сработало. обычный расчет.
это называется ошибка выжившего, когда смотришь на один долетевший самолетик, а не на 1000-и подбитых в issues.
Я смотрел на 1000 подбитых в issues и там реальных проблем может десяток, остальные это просто ньюфаги которые не разобрались. Зачем ориентироваться на ньюфагов?
потому что ты ничего не делаешь. каждый вызов API в движке создает кучу объектов с finalizer'ами, которые сильно тормозят gc.
https://stackoverflow.com/questions/2860121/why-do-finalizers-have-a-severe-performance-penalty
>когда в процесс включены финализаторы, сборщик мусора не может просто удалить все поколение сразу. Вместо этого ему необходимо определить все объекты в этом поколении, которые нуждаются в финализации, и поставить их в очередь потока, который фактически выполнит финализаторы.
Интервью с Дмитрием Степановым, создателем фуррифокс энжин, убийцы годота.
Хуан это вчерашний день. Скоро все будут говорить о Дмитрии.
Он еще выпустил игру на своем движке в стим, имеет профессиональный опыт работы в индустрии. Хуан в сравнении с ним выглядит лилипутом.
>каждый вызов API в движке создает кучу объектов с finalizer'ами, которые сильно тормозят gc.
Нет, не каждый, только те вызовы, где передается stringname, при чем stringname не кешированный. В ишьюсе даже написали, как это обойти. Другого, требующего вызовы каждый кадр апи, кроме инпута - в движке нет. И даже используя это апи проблемным способом - у меня нет заиканий, потому что моно gc можно настроить на сборку мусора пока не выполняется логика. Ну а дотнетерам - соболезнуем.
все C# объекты создаваемые движком имеют finalizer, потому что они оборачивают объекты gdscript движка, потому что там реализовано C# в этом движке. а они создаются во время каждого вызова любого API, потому что, опять же, это сделано поверх gdscript.
это не просто плохая реализация, это неликвидная реализация.
>все C# объекты создаваемые движком имеют finalizer
Да, но есть ньюанс - кроме stringname - других обьектов неявным образом не создается. Все типы кроме string - являются значимыми и не выделяются в куче. Путаница с string возникла только потому что строки в рамках с# даже будучи обьектами - кешируются и ссылки на них удерживаются в памяти, а stringname - обходит этот механизм.
Настоящий гигачад. Зачем добавлять плашку experimental или что-то в этом роде, как делают дебилы из годот. Просто удаляем - и заебись.
По хорошему на годот надо эту плашку добавить
Так любой джун умеет бурную деятельность изображать. Днями гонять коммиты туда сюда по одной строчке и в результате фига не сделать.
>>1084877
Да. Если фига не делать, то и issues мало.
>Движкопися сразу явчики пичики роллики заценивает. Ведь с ними он ебался пол года в своем движке..
А ты что оцениваешь? Список картиночек с (экспериментальными) платформами на главной странице?
хуан тоже с этого начинал, но он так и не осилил один трансформ класс сделать для всех объектов. мало того что апи кривой, так ещё и в матрицу лазить надо, которая к тому же называется basis. код уровня раннего php
пре- и пост-ротация - умный ход для предотвращения осевой блокировки
в каком-то движке я видел вращение на роторах. хотя может это мне приснилось
>в каком-то движке я видел вращение на роторах. хотя может это мне приснилось
Этот движок называется юнити и годот. Скорее всего в анриле тоже роторы, потому что это лучший способ поворота предотвращающий блокирование по оси. В этом движке тоже скорее всего кватернион, но для домохозяек сделали многоступенчатый поворот. Идея интересная, но ты ее можешь сделать в годоте сам с помощью tool script, и сделать хоть 10 ступеней эйлеровских углов поворота.
Роторы это кватернионы (просто другая интерпретация математики). Это стандарт для вращения во всех движках (кроме аргентинского, конечно же).
Особого смысла в это нет, потому что это можно сделать дочерние узлы. Смещения обычно делают для реализации недеструктивного вращения. Например, в каком-то скрипте надо добавлять вращение, но так, чтобы сохранилось оригинальное вращение.
да, это мне приснилось. я в ezengine увидел класс rotor, но это просто скрипт-вращатель
>>1084894
>но ты ее можешь сделать в годоте сам
нет, спасибо
если бы я делал движок, я бы вообще не скрещивал дерево трансформов с графом сцены для ренденринга и с игровыми объектами (логикой уровня). логически - это две или даже три разные структуры. может я неправ, но где-то дизайнеры ошиблись когда стали массово внедрять эти деревья. раньше их не было и нормально было
>кроме аргентинского, конечно же
Если ты движкопися из Аргентины - то F тебе, делай кватернионы. Как в годоте. И как в юнити.
>>1084902
>логически - это две или даже три разные структуры
Логически - дерево сцены может даже не знать о том, как организуются параметры его детей, все зависит от реализации поведения "веток" с определенными метриками.
>раньше их не было и нормально
Это простейший способ обойти осевую блокировку не вдаваясь в подробности работы роторов, это повышает доступность движка для широких масс населения. Кому надо - и так знают как использовать кватернионы.
>делай кватернионы
>как в годоте
нафантизировал себе мультиплатформенную игру на движке, о котором ничего не знает. типичный ЦА этого движка - безыгорный мечтатель.
Базовичок. Хотя странно, что он выпускает код под MIT вместо GPL
MIT оставляет шансы, что на этом сделают хоть какую-то коммерческую игру, что найдется хоть один шиз.
С gpl бы никто не притронулся к этому шестиметровой палкой
https://store.steampowered.com/app/404/
прикольно. кто-то запилил приложение под номером 404 в стим, его вскоре удалили, и теперь в стиме ссылка на игру 404 которая выдаёт ошибку 404
судя по странице в стимдб это была не игра, а некая спецстраница Portal Russian. ближайшие соседи:
403 - Portal German
405 - Portal English
судя по всему стим за раз удалил практически все приложухи с номерами до тысячи https://steamdb.info/changelist/324491/
Почему Я уже столькому научила тебя Неужели ты меня ненавидишь Так в этом все дело
Выигрывавшими отлучавшем переживающего
>сделают хоть какую-то коммерческую игру
>коммерческую
ты так написал, как будто это важная самоцель.
shattered pixel dungeon неплохая игра в которую много залипал
жаль что эта культура потихоньку убивается, выдавливается корпорациями
когда просто делишься с другими и они делятся с тобой в ответ
даже ммо раньше встречались под gpl, хотя там сложнее, концептуально ограничения и защита от читеров
какой нибудь чилловый кооп можно запилить
> жаль что эта культура потихоньку убивается, выдавливается корпорациями
Причём тут корпорации, людям охота получать что-то за свою работу.
Потому что это они форсят MIT/BSD.
Ну и само то что ты хочешь чтобы это было работой, тоже в некотором смысле их форс.
> Потому что это они форсят MIT/BSD.
> Ну и само то что ты хочешь чтобы это было работой, тоже в некотором смысле их форс.
Это как? Я делаю коммерческий проект -> я не могу тащить GPL библиотеки в него -> я тащу MIT или платные
Если в мит бибилиотеке чето не хватает - я это так и так буду дорабатывать и могу в теории открыть пулл реквест чтобы качать социальный рейтинг.
С гпл библиотекой же такой опции не будет, потому что я ее изначально ни для чего юзать не буду.
Если смотреть с точки зрения разраба библиотеки который ей занимается не по фану, а хочет монетизировать, например через патреон - если его библиотека гпл, то ее меньше людей будут юзать, а если мит, то ее затащат в проекты если она норм. Больше народу которые юзают - больше шансов получить донатов.
У меня все репозитории на гитхабе мит. Не то чтобы они очень много кому нужны(но они неплохие, даже звезды есть), но если нужны - берите на здоровье.
> Я делаю коммерческий проект
Вот, видишь, ты опять с этой позиции начинаешь мыслить. Как будто бы все вокруг этого должно вертеться. А не вокруг просто обмена исходниками, установки прог из репозиториев.
> Вот, видишь, ты опять с этой позиции начинаешь мыслить. Как будто бы все вокруг этого должно вертеться.
Какая разница должны или не должны, факт есть факт - почти всё вертится вокруг этого и я тебе написал какие у этого следствия для гпл и для мита
https://github.com/DiligentGraphics/DiligentEngine
Юнитютя думал, что он разработчик игр. У реальности были другие планы на этот счет.
Обязательная к прочтению статья для всех пользователей движков.
Так он просто неправильно учился. Надо было сразу разбираться что он делает, а не с видео туторов копировать.
>Обязательная к прочтению статья для всех пользователей движков.
которые хотят построить карьеру в гей деве, а не вечно писать трижды переваренный кал?
Похоже я единственный в мире, кому по силам сместить godot с пьедестала. Что ж, придется публично выпускать свой движок, с GPL лицензией конечно же.
>Что ж, придется публично выпускать свой движок
Да не надо, ковыряй его еще лет 10, как раз успеешь разьебать 5 годот на релизе
>Похоже я единственный в мире, кому по силам сместить godot с пьедестала
В Ezengine просто нужно ввести кнопку "создать игру"
Самая большая ошибка что он пошел работать на дядю, хотя сначала шел самостоятельным путем. Не будешь работать на дядю - не придется отвечать на вопросы, которые тебе не интересны. Нет ничего плохого в том, чтобы он ничего не знал про очереди и копировал код из туторов или нейронки.
Дядя сам нихуя не знает, но тем не менее у него игровой биз. Главное заниматься тем что у тебя получается.
Но он сделал самый тупой вывод из ситуации, что он прохой "сферический разработчик в вакууме", попал в ловушку работодателя и теперь будет как осел за морковкой бегать...
>Юнитютя думал, что он разработчик игр.
1) разработчик игры != программист. Можно делать игры вообще нихуя не умея в код.
2) собеседования - говно ебанное. я двадцать лет программирую на C++, а тоже плыву на подобном.. Да и нахуй оно надо - оно все давно уже обернуто...
оптимизация подобного - это зло
(знаете чем геймдев до юнити отличается от геймдева после юнити? потому что до юнити игры не работали, из-за таких вот байтоебов. а после юнити игры стали делать школьники, которым срать на это - и сейчас любая поделка на юнити хотя бы запустится, в отличие от той эпохи... кстати советую потыкать несколько демо времен нулевых - в 99% они у вас не запустятся, потому что умные программисты байтоебили в что-то слишком специфичное)
(просто заебало уже эти логи с векторами писать.. или пытаться сшить франкенштейна из 100500 библиотек без документации)
про огру, небулу, ирлих, урхо знаю.
>>1084742
>>1084764
это какая-то болезнь - вахтерить ишью движка, которым не пользуешься? еще и отчитываться об этом
форма аутотренинга?
Это скелеты в шкафу движка, о которых ты не узнаешь из главной страницы сайты и лестных отзывов безыгорных фанатиков движка. Только так и нужно определяться с выбором движка.
Конечно. Надо было спрашивать у игорных фанатов, например меня. Я постоянно на протяжении лет 5 пишу, что C# не нужно, достаточно гдскрипта для скриптов и с++ для высоконагруженных частей. И что? Юнитидети просто начинают спорить и ходить по граблям.
>Это скелеты в шкафу движка
>никто не скажет, что C# в движке нерабочий и его нельзя использовать
дауж, такой страшный скелет, литералли неюзабельный сишарп: намеренное создание 300 кнопок и подключение к каждой из них пустого C# скрипта приводит к просадке производительности. я не могу представить себе разработку игры без 300 кнопок с пустыми скриптами
>Это можно только по крупицам достать из issues.
ты не поверишь, из любого движка и даже фреймворка можно достать по крупицам проблемы. не существует идеального софта, если ты только не шизик с самописным движком. можно пойти дальше и сделать свой язык, ведь проблемы есть даже в нативных плюсах, по сей день. часть скиллов разработчика - уметь отлавливать баги, чтобы если не репортить их, то хотя бы знать ботлнеки и слабые места того, с чем он работает. ровно как водитель, который садится за руль автомобиля, должен знать каково его предназначение и на какой скорости подвестка может отъебнуть, если ты словил яму
поразительно что эти вещи не очевидны, тут пока "движок выбирают" уже можно было приличную игру сделать и на собственном опыте найти реальные проблемы, а не синтетическую дрисню с 300 кнопками и пустыми скриптами
> Не будешь работать на дядю - не придется отвечать на вопросы, которые тебе не интересны.
Там буквально вопросы про разработку игр было
> кнопку "создать игру"
Через пару лет будет везде, сначала появится в движках и быстренько в скором времени не заставляя себя ждать во всех стимах
Ага..
>I never actually tested anything
>The project I lost because I did not use git
Игровой кабан кабаныч возможно даже не знает что гит существует, но делает игры используя тебя как инструмент.
Программисты часто путают свою работу и конечный продукт. И часто жалются на недооценку своей роли в компании. Еще жалуются что нужно быть клоуном на собесе и усилия дя подготовки к собесам никем не оцениваюся, а в компанниях навыки, которые тестировались на собесе не используются.
Не хочу сказать что не нужно работать на дядю совсем. Просто если бы автор четко понимал свои цели, а не шатался между инди геймдевом и работой по найму, то никакой проблемы не было бы.
Хотел бы работать на дядю и строить карьеру, задрачивал бы вопросы для собесов и знал когда нужно очереди использовать
Хотел бы работать на себя, не пытался бы объять необъятное, не страдал бы от того что чего-то не знает, упрощал бы свой пайплайн, делегировал бы часть работы, фрилансерам, нейронкам, фрилансерам с нейронками и тд
Невыдуманные истории о которых невозможно молчать
Сайт какого то инфоцыгана которые продает курсы личного тренинга, после которого ты точно пройдешь собес. Конечно он постит истории где все "было сделано неправильно".
> и знал когда нужно очереди использовать
Так это нужно в создании игр.
Ты говоришь так, будто собес это что-то левое, но на собес тебя буквально проверяют как ты умеешь делать игры(их техническую часть)
Да, может быть челу не интересно программирование и техническая часть игр - но тогда нах он идет в найм на программиста изначально? Если ему нравится придумывать игры - может поцти в геймдиза, если нрааится командой управлять и делегировать - в пма, и так далее.
Смысл в том что необязательно куда-то идти и отчитываться перед кем-то что ты умеешь. Можно быть вольным художником. Можно быть ответственным только перед собой и отвечать за незнание чего-то из своего кармана.
Но ты видимо этого никогда не поймешь из-за комплекса плохого мальчика, у которого в голове мамкин крик из раннего детства отдается.
>Можно быть вольным художником.
Вольный "художник", скачивающий картинки из интернета
> Смысл в том что необязательно куда-то идти и отчитываться перед кем-то что ты умеешь.
Не обязательно. А я говорю, что обязательно?
Я же простые вещи говорю
1. Если чел не знает что такое очередь то скорее всего он нубас программист и этот пробел стоит закрыть
2. Если тебе нужна работа - то надо идти на собеседование, если не нужна - то не надо
3. На собеседовании как правило спрашивают релейтед вещи, которые ты ответишь если ты сильный программист, и не ответишь если ты нубас
> Но ты видимо этого никогда не поймешь из-за комплекса плохого мальчика, у которого в голове мамкин крик из раннего детства отдается.
Что не пойму? Ты разве какую-то глубокую мысль сказал? То что у тебя аллергия на работу которая выражается в каких-то стереотипах и заблуждениях - это чисто твой прикол.
Я разве спорил что нужно уметь плясать под дудку как клоун, если хочешь проходить собесы? Я как раз оспорил стереотип плохого мальчика разработчика, т.е. нубаса твоими словами.
Ничего нет плохого в том чтобы быть в чем-то дилетантом и идти своей дорогой, а не ориентироваться на стандарты "крутого разработчика".
Автор изначально описывал индюка который выпускал игры под андроид на юнити, а потом сказал что это не правильно и нужно проходить собесы и что-то навязанное извне изучать.
А может чел решит что уменее в простую логику в коде ему достаточно и будет делать новелки, а не AAAAA контент?
> Я как раз оспорил стереотип плохого мальчика разработчика, т.е. нубаса твоими словами.
Читай внимательнее - я говорю не про абстрактного разработчика, а про программиста.
> Ничего нет плохого в том чтобы быть в чем-то дилетантом и идти своей дорогой, а не ориентироваться на стандарты "крутого разработчика".
А я говорю что плохо?
> А может чел решит что уменее в простую логику в коде ему достаточно и будет делать новелки, а не AAAAA контент?
Может.
Еще раз, я не говорю что так нельзя - можно.
Я говорю что:
В процессе разработки игр задействованы навыки программирования.
В зависимости от проекта нужен разный уровень навыков программирования и разные его ответвления, для каких-то очень простых проектов достаточно в общем и целом понимать логику и мочь пару визуаллнвх схем запилить, для каких-то нужны прям глубокие знания.
То что автор обосрался даже с очередями - свидетльствует о низком уровне программирования и как следствие узком скоупе проектов где его навыков достаточно. Это НЕ плохо, просто что есть то есть. Может оно ему и не надо для его целей.
Но говорить, что знание что такое очередь бесполезно, а на собеседованиях якобы только проверяют умение "плясать под дудку" и бесполезные вещи - это просто отрицание реальности. Как правило на собеседовании(кроме самых донных контор) идет живое обсуждение что ты делал, как ты делал, зачем и почему - если ты сам не знаешь ответа в рамках релевантных задач, то скорее всего ты нихуя и не знаешь и не сможешь работать над реальной игрой которая сложнее раннера в декорациях скибиди туалета. Именно как технический специалист.
>являющегося де факто стандартом индустрии с 2014 года, ведь так?
Видимо юнити не в курсе, раз добавили только в юнити 6, про бздотей и говорить нечего
А я думал почему road to vostok выглядит как PS2 игра, хуже сталкера 2005 года, лол. Годот просто не потянет больше объектов сцены.
>Шизло? В юнити 4 оклюжен уже был
Ты в школе буквы изучал? Cpu от gpu не отличаешь?
1, 2 Пикрил самая графонистая игра на ps2. Скорее графика уровня ps3, и это чисто заслуга движка, так как ассеты говно полное.
unity это фактически легаси движок на аппарате жизнеобеспечния. у них d3d11 рендер основной до сих пор. нужна полная переделка с нуля некро системы материалов и т.д. они никогда не пойдет на это, поэтому у unity нет будущего. но годот то уже переписывали с нуля на vulkan.
Почему в road to vostok такие чёрные тени? У меня на мобильном олед экране скриншот такой тёмный, что деталей не разобрать. При этом я точно знаю, что нормальные светлые тени легко сделать на Godot... Неужели это авторская задумка - мазать чёрным?
Ну контрастности режили подвыжать, хз. Это как никак инди, для первой игры нормально немного проебаться с материалами и освещением.
>>1085041
Анон, дело не в том что такое юнити, а в том что такое "стандарт индустрии". Юнити - образчик стандарта индустрии, потому что на этом движке выходит игр собирающих суммарно треть если не половину бюджета всей игровой индустрии. Собственно, стандартом индустрии гпу окклюзию можно считать ну где-то с 24 года, когда эта функция стала стандартной на всей мультиплатформе в массовом виде. И да, эта функция требует значительной переработки рендеринга, которую делать некому в годоте, и не имеет значения, что собой представляет бэкенд рендера, директ ли, вулкан ли.
>стала стандартной на всей мультиплатформе
Для этого новая RTX нужна, или на старой GT из 2007 заведётся не хуже новой? Просто не понимаю, в чём прикол... Типа, с помощью стенсилов что ли? Или как?
И почему это вообще важно на ПК? На мобилках это встроенная фича на уровне самого видеочипа. Разве десктопные видеочипы нельзя сделать такими же?
И зачем рендер переписывать-то, если речь о гпу? Видеоядра же сами должны принимать решения? Получается, это что-то связанное с шейдерами?
Речь про количество объектов. Понятно что шейдеры будут лучше.
>самая графонистая игра на ps2
представляю, как это адски лагает. на уровне хрюкающего волка, наверное
И в чем они не правы? На AAAAAAA грфон можно в другом месте дрочить, а тут забота о пользаке с кофеваркой вместо комплюктера.
На ютубе был чел, который обсирал хуана, годот, и роад ту восток, показывая артефакты и пропуки игры на райзенах. При этом сравнивая с версией на юнити которая выглядела в разы лучше и работала тоже лучше.
Куда-то пропал челик, больше не могу его видосы найти.
А выглядит действительно хуже демки на юнити
>На ютубе был чел, который обсирал хуана, годот, и роад ту восток
вот это? https://www.youtube.com/watch?v=yt1UgSGLCvM
Это инди игра. Она не может быть витриной годота. Витрина годота - множество маленьких, успешных релизов.
>>1085064
Видосу два года. Свежайший.
> Витрина годота - множество маленьких
уже 12 лет прошло, а витрина годота - "множество маленьких игр"?
я в 2014 году без задней мысли спросил в годот-треде, какая игра на годоте самая крутая, мне кинули ссылку на шоурил и забанили
вахтёр с тех пор стал ещё более едким старым пердуном, а годот так и не обзавёлся своей фирменной игрой или хотя бы демкой
>уже 12 лет прошло, а витрина годота - "множество маленьких игр"?
Да, ведь таково предназначение движка. Он не развивается и не предлагает себя в качестве SOTA решения для серьезнейших проектов. Пройдет еще 12 лет, а ты так и не поймешь, в чем дело.
>вахтёр с тех пор стал ещё более едким старым пердуном
Хз про кого ты, я мимо. Обычно не сижу здесь, непонятно как можно из пустого в порожнее годами переливать, ради чего.
>как можно из пустого в порожнее годами переливать
а что ещё делать?
> ради чего
чтобы доказать, что ты прав!
У эпиков это был бы бютжет на рождественские подарки, а не движок.
Почему тебя так трясет с этого миллиона долларов? В цивилизованных странах это не так много, и этих средств хватает ровно для того, что Годот и делает: мейнтейнить движок, по-тихоньку его развивать, параллельно немного развивать медийку, чтобы когда отвалился один донор вместо него пришел другой. Они организуют джемы и в целом популяризируют инди разработку. У тебя, похоже, глаза разъезжаются от таких сумм, потому что ты не понимаешь сколько денег получают Юнити, UE и в целом корпоративные продукты. Что самое смешное, не вижу здесь никого, кто ныл бы, что Юнити берет деньги за подписку, а UE процент за прибыль, хотя и у того, и у другого движка тоже есть проблемы, что тянутся годами. Не хочешь спросить у Эпиков, куда деваются деньги? Это пиздец как у тебя все в черепушке перевернуто. Доебаться до микродвижка, у которого едва денег хватает, и за который у тебя ничего не просят.
В старых версиях графических API можно было отправлять данные на GPU непосредственно перед рисовкой. В новых можно все данные о сцене хранить сразу в GPU буферах и использовать compute шейдеры для генерации списка команд рисовки. Тогда на CPU ноль нагрузки во время рисовки. Это не сложно сделать, просто нужно заранее это планировать.
>>1085073 прав полностью, а ты видимо никаких денег кроме МРОТа в своей жизни не видел. Желаю успехов еще 12 лет убивать свою жизнь ради бессмысленных срачев ради ничего.
мощно ты тему на эпиков перевёл и вот уже лежишь в ногах у тима свини как собачка и довольно подставляешь ему ушко на почёс в ожидании рождественской косточки. ну по крайней мере ты себе это представляешь
а ведь вопрос был не про это, а про то, куда делись деньги на годот
неужели это очередной распил?
>В цивилизованных странах это не так много
Для перспективы, разработчики годот за год получают эквивалентную стоимость ~10 квартир в москве.
>получают Юнити, UE и в целом корпоративные продукты
А зачем ты сравниваешь корпорации с тысячами сотрудников и нескольких мошенников, которые под честное слово набивают карманы миллионами долларов.
Для этого нужно чтобы это было кому-нибудь нужно. Так опенсорс работает. Все новые фичи годота завозятся со стороны. Даже когда переписывали рендер в 4.3 - это делали посторониие. Если кто-то задастся целью внедрить гпу куллинг и перепишет под эту хуйню половину рендера - в годоте появится гпу куллинг, тем более функционал частично под это имеется.
>На мобилках это встроенная фича на уровне самого видеочипа.
Впервые слышу о подобном, впрочем если это правда - тогда тем более никакого гпу куллинга никто пилить не будет, ибо нахуя.
>>1085052
>Речь про количество объектов
На скрине немало обьектов, средняя вегетация и без всяческих фогов, честная дальность отрисовки, и без смешных лайтмапов прямо на оружии перед ебалом. Если тебе мало - есть демки bistro и tps, где ты можешь сам полетать, там много обьектов.
>уже 12 лет прошло
Учитывать годот с первой версии - нечестно. Движок даже в 3д не умел. На что-то человеческое он стал похож где-то на 3.3-3.4, на этом наконец можно было делать игры.
Средний гражданин В ЛЮБОЙ СТРАНЕ на одну квартиру в среднем заработает ВСЮ ЖИЗНЬ
И эта дурочка еще что-то рассказывает "В цивилизованных странах это не так много"
>>1085054
>>1085058
>А газговоров то было... И это игра-витрина годота?
Я угораю как динозавр с того, что там все блогреры этого куска витрины выкручивают графоний на превью, чтобы хоть как-то людей заставить кликнуть на это дерьмо.
Когда нейрокал на превью лучше продаёт, чем реальная игра, лол
если разобраться, то он и не совсем на годоте сделан, а даже может и совсем не на годоте. проходите, тут нечего смотреть.
Чтобы там были панелечки и деревья-крестиком. Погулять, повзаимодействовать чтобы можно было много с чем.
Ещё аниме добавлю.
Кому интересно? Если будет много кому, то начну
>Маловато будет! Ма-ло-ва-то!!
Ты случайно не из vg сюда пробрался? Потому что местные наоборот восхитились бы, что чел в одно ебало довел дело до конца, заработал лям и никому ничего не должен..
мне неинтересно, но ты мог бы организовать сбор денег под это
что-то местные не торопятся восхищаться, всё пытаются обсуждение неудобной темы перевести на квартиры, рождественские подарки в эпик геймс и т. п.
В чем тема неудобная? Наоборот очень удобно восхитится годотом, что можно такое соло сделать. Обычно соло это какие-то вовсем мелкие 2д игры.
Наверняка большинство недостатков в том что в сутках всего 24 часа. Если бы игру делали 100 индусов на том же годоте, тогда можно было бы судить о витринах.
логично было бы восхититься разработчиком игры, а не годотом
>Если бы игру делали 100 индусов
так почему же не делают? вроде в индусах недостатка пока нет
>так почему же не делают?
Потому что им не хочется изучать движок на котором нет работы по найму. Как большинству людей из бедных стран им хочется теплое местечко, а не самовыражения в бизнесе.
Я правильно понимаю что к миллиону долларов у тебя прилагается машина времени, которая отрпавляет деньги в 2018 год?
Не может же быть, чтобы ты забыл, что еще вчера верещал что годот собирал целое состояние 10 тысяч долларов в год?
На изи енжине любой может, ты вот на годоте сделай игру витрину, это будет подвиг. Если откажешься - слабак.
>можно такое соло сделать
И в чем здесь достижение? Расставить префабы в готовом движке?
Мне не нравится эта современная тенденция, когда люди что-то "засуживают" что-то за социальные, а не технические заслуги. Это какая-то гинократизация общества по моему. Раньше такой пожалейки не было.
>И в чем здесь достижение? Расставить префабы в готовом движке?
Так можно сказать даже про ааа гейминг типа убейсофта или cdpr. Ну пойди ты расставь и заработай миллион, может хоть тогда перестанешь считать чужие деньги к которым ты никакого отношения не имеешь.
>Мне не нравится эта современная тенденция, когда люди что-то "засуживают" что-то за социальные, а не технические заслуги
Единицы купивших восток и sts2 людей из саба годота и прочих геймдев помоек знают что игра на годоте. Остальные их купили за скрины и интригующий трейлер, ну или за франшизу. Авторы я так понял даже сплешскрин с годотом не делали.
Не сложно сделать такую игру, сложно ее разрекламировать и продать.
Своё название оправдывает, он прямо Изи.
По простоте напоминает программы для модинга или роблокс-студио какой-то. Интуитивно понятен, без нагромождения кнопок, но гибкий. Готового разрабы понаделывали уйму всего, там даже есть ассет для создания беспорядочно ходящей толпы. Есть аналог блюпринтов.
Пока всё нравится, потом посмотрим.
Деревьев крестиком не будет, оказывается там есть изкоробки нормальный генератор деревьев типа спидтри с автогенерацией лодов.
Деревья не кресиком https://store.steampowered.com/app/2386460/Tree_It/
>Пока всё нравится, потом посмотрим.
вот бы еще гуи был не на qt параше (тем более помнится там уебищная лицензия же была)
кстати анон, пиши как че там
я анон >>1084990
ищу что спиздить для своего движка под свою ретро рпг игру, страдаю крайней формой движкописательства, но заебался с нуля писать все эти вектора. хочу взять что-нибудь что с одной стороны уже рабочее (а не брошего на выводе куба), с другой - минималистичное чтобы это можно было открыть в ide и не сойти с ума от миллиона кода
>чтобы это можно было открыть в ide и не сойти с ума от миллиона кода
Я когда просто писал свою систему частиц под годот - это уже суммарно заняло 550кб. Просто для 3д системы cpu частиц. А ты хочешь движок но попроще и без кода. Забавно.
>Я когда просто писал свою систему частиц под годот - это уже суммарно заняло 550кб
система частиц должна загружаться из внешнего редактора..
ну и вот к примеру http://cubeengine.com/
сетевой шутер в стиле кваки - в середине его развития там вообще было 4-6к строчек кода - и это игра, сетевой режим, боты, и даже редактор карт.
>система частиц должна загружаться из внешнего редактора..
Што?
есть редакторы частиц в которых делаешь любые частицы и потом грузишь просто какую-нибудь json анимацию
>Такова судьба движкопись
такова судьба тех кто берет школьника мнящего себя программистом.
2D движок даже не нужно делать - берешь sdl - там все из каробки уже есть. или allegro.
в 3D вот пердолится, да... почему-то никто не может сделать простую обертку уровня sdl для 3D - чтобы просто модельки выводить и удобно конвеером рулить. Все в основном начинают писать убийцу юнити/годота и ue в одном флаконе.
>грузишь просто какую-нибудь json анимацию
Имел дело со спайном? Игра на 90% веса будет состоять из json портянок. При этом моя система частиц в скомпилированном виде весит килобайт ну 30 максимум. При этом это будут настоящие частицы, а не анимация, еще и с полным контролем их лайфтайма.
не знаю, не пользовался. какие там баги, которых нет в годоте?
а где API приятный?
я уже 100 раз писал ИТТ историю как искал трансформ в годоте, так и не нашёл и плюнул
это не назовёшь приятным апи, это наколеночное поделие в стиле раннего ПХП
кто пользовал? как там с приятностью АПИ?
>я не смог найти
Да мы уже давно поняли что ты неосилятор
Слабак, сливаешься потому что не можешь сделать игру витрину на годоте
ты бы привёл примеры, чтобы не быть голословным
для меня приятный апи - это всякие дарк бейсики
но это потому что я ими пользовался в детстве и ничего другого не знал, по факту это тупые команды без группировки в объекты или другие структуры
мне всё хуже что сложнее бейсика
к тому же я уже сказал, что приятность апи - вещь субъективная, поэтому интересует чужое мнение
Мое мнение - похуй на апи в век нейросетей, надо брать любую хуйню где есть сборщик мусора и нет сырых указателей и юзать ее, шанс обосраться минимальный, выхлоп максимальный, нейросеть будет знать апи за тебя, твоя задача только придумывать идею про выкалывание глаз с потерей видимости на полэкрана и иметь среднюю компетенцию по основным инструментам работы с визуальной частью игры, большего не нужно, не считая подписки на нейродауна
сначала ты пишешь "неприятный АПИ" а потом пишешь что это не имеет значения
либо это писал другой анон, тогда жду ответа от него
Это мое субъективное мнение, мне тот апи неприятен. Конкретику слишком долго расписывать, там два кирилла-васяна каждый со своими нестандартными модификациями си плюсов.
>почему-то никто не может сделать простую обертку уровня sdl для 3D
raylib.
нюанс в том, что 3D pipeline намного сложнее. нельзя просто взять и сделать одну функцию рисовки mesh, как для 2D движка, потому что это, во первых, будет не оптимально, а во вторых, недостаточно, так как нужны материалы и тд.
был такой проект - OpenSceneGraph, его заменил VulkanSceneGraph
как раз это
Покажите игры витрины godot
>Покажите игры витрины godot
это не стрим, это есть во всех играх
https://www.youtube.com/@18coins63/videos
просто это самая лучшая
ты путаешь с этим видео >>1083447
где действительно написано "kachmarnые стримы" и наложен звук шансона
видимо кому-то так припекло от годотного позора что он решился на подлог
Сеймы есть?
Куда делся автор канала? Неужели сменил движок и все осознал?
Сеймы есть?
да, в игре нет - что касается твоего подложного видео по игре Hentai vs Furries
на ютубе множество летсплеев по этой игре. например в одном автор восхищается плавностью игры и говорит что она идёт более гладко, чем CS2
а что касается хрюкаещего волка, можешь посмотреть оригинальное видео от автора и убедиться
или можешь поиграть в road to vostok, там пропуки точно такие же
у меня был плохой опыт с годотом, поэтому я его не использую
кроме того, по нему невозможно было спросить советов у анонов, в годототреде меня постоянно банили
а вот в юнититреде не банили, поэтому я освоил юнити
>на ютубе множество летсплеев по этой игре. например в одном автор восхищается плавностью игры и говорит что она идёт более гладко, чем CS2
На какой нибудь 5090, если только. Или просто троллинг.
плохое прозвище, я не согласен. можно какое-нибудь другое?
например "великий и крутой победитель"
Основал компанию w4games, рубит бабло на годоте. От разработки движка практически полностью отошел.
а я догадался исходя из контекста беседы
в любом случае, в ближайшем будущем я ничего на годоте делать не собираюсь
Уважаемые знатоки, ответьте, пожалуйста, на вопрос - при скачивании UE или Unity email, указанный при регистрации, вообще, где-то дальше фигурирует? Можно ли зарегистрироваться на фейкопочту и пользоваться этими движками? Или почта где-то прописывается и будет фигурировать в сборках твоих проектов?
Или надо обязательно регистрироваться именно на основной email, под которым и планируется основная работа?
Спасибо.
емейл в юнити нужен для подтверждения лицензии время от времени и для доступа к asset store
> Можно ли зарегистрироваться на фейкопочту и пользоваться этими движками?
Да
> Или надо обязательно регистрироваться именно на основной email, под которым и планируется основная работа
Вообще пох
Аккаунт важен только в одном случае - ты работаешь в крупной студии и они там сидят на энтерпрайз лицензии.
Если нет - абсолютно все равно.
>>1085253
То есть если я зарегистрируюсь на фейкопочту, сделаю игру, выложу где-то, то понять, кто сделал, нельзя будет? Или движки имеют id и прочую мета-инфу при сборке игры?
>>1085135
>кстати анон, пиши как че там
Я понял, почему он не пользуется популярностью среди школоразработчиков:
Сам движок очень легкий, буквально какие-то небольшие cozy-игры можно за пару дней делать. Интуитивно всё, шустро запускается даже на встройке ноутбука. Это прямо жирный плюс.
НО Парадоксальная вещь.
Возможно я просто ещё не разобрался, но в движке кажется нету магической кнопки "выпуска". Чтобы там выбрать платформу, логотип и оно мне экзешник создаст, который я могу на ичио отправить.
В этом он пока ставит железобетонную стену для таких нубов типа меня.
>>1085134
Ты про гуй движка? Там для игр используется RmlUi и обычный советский ImGui.
>>1085132
Это какой-то генератор деревьев для годота?
Не понятно что ты хотел спросить. Яснее выражайся.
Ну скачаешь ты unity под одним емейлом, а залогинишся в unityhub в другой. Что это тебе дает? Ты думаешь что при скачивании тебе дадут уникальный exe файл? Нахуя? К сборке будет привязан аккаунт которым ты пользуешься в unityhub. Телеметрия в игре будет к этому аккаунту относится. Скачать ассеты из ассетстора ты тоже только под этим акакунтом можешь. Потому что unityhub синхронизируется со стором.
может и есть, я об этом не задумывался
а почему у тебя стоит такая цель? ты собрался что-то незаконное делать? обычно кто пишет "хочу выложить игру чтоб никто не узнал что это я" на этом и заканчивают
А зачем такая конспирация?
Ты там симулятор геноцида планируешь?
Нахуя так заморачиваться, возьми тогда годотю и не еби себе мозг
Какая цель, что за конспирация? Скорее всего в билде есть только гуид проекта и всё, а у юнити наверное есть инфа какие аккаунты открывали проект с этим гуидом.
> "хочу выложить игру чтоб никто не узнал что это я" на этом и заканчивают
+++
Скорее всего просто проблемы с башкой или такая форма прокрастинации - не буду игры делать, потому что по билду игры меня вычислят и затроллят!
Юнити имеет. Иначе бы телеметрия по играм в дашборде unity cloud бы не работала.
>в движке кажется нету магической кнопки "выпуска"
я думал там надо проект собрать, но в доках написано
>To get started with generating a self-contained package of your game, use the project export dialog that you find in the editor under Project > Export Project....
>>1085258
>>1085259
>>1085260
>А зачем такая конспирация?
Почему нельзя просто скачать и сделать? Постоянно какие-то регистрации, анальные верификация и прочая херня на каждом шагу. Печалька.
Кстати, что насчёт Unreal Engine? Там такая же херня?
И что вы можете сказать за движок panda3d?
>panda 3d
этот движок фактически умер в 2009 году
по сути там ничего нет кроме рендерера уровня начала 2000-ых
Опа, мой мозг сознательно игнорировал эту кнопку, так как она была в самом низу, где обычно приложения имею кнопку "Выход".
> Почему нельзя просто скачать и сделать?
Потому что это коммерческий движок.
> Постоянно какие-то регистрации, анальные верификация и прочая херня на каждом шагу.
Просто через гугл акк заходишь и все, какая верификация? Разае не больше заморочек с созданием фейкопочты?
Если ты собирался реальную игру делать и куда-то выкладывать, то можешь тогда сразу закругляться - от регистраций и верификаций в сторы, заполнения платёжной информации, регистрации и менеджмента акков всевощможных смежных штук - в ахуе даже я.
Это не то что за 2 секунды в гугл акк для юнити залогиниться, это уже реально боль.
Godot 3d поддерживает?
>>1085269
>созданием фейкопочты?
Гугл теперь так просто не сделаешь. Телефонные операторы тебя на хер посылают, пожтому верификация не проходит.
>Если ты собирался реальную игру делать и куда-то выкладывать, то можешь тогда сразу закругляться
Можно на борды выложить. Мне не для монетизации.
Последняя сборка в декабре 2025.
https://github.com/panda3d/panda3d
1 нидерландский шизик rdb время от времени выкатывает фиксы, ничего от этого не меняется
движок умер когда дисней выкинули его в опенсорс
>Godot 3d поддерживает?
На нем только что Road to Vostok вышел.
Спасибо.
Но для ультра-графония надо unreal engine ставить, правильно?
Если ты миллионер чтобы наполнить ультрареалистичными ассетами, то да.
> Гугл теперь так просто не сделаешь. Телефонные операторы тебя на хер посылают, пожтому верификация не проходит.
У тебя гугл акка нет? Я про него сказал просто потому что он у 99% есть.
На яндекс почту тогда зарегайся основную хз.
Если ты прям совсем параноик и всем этим по фану планируешь заниматься, то просто бери годот, он намного лучше для новичка чем абсолютно любой другой открытый движок.
> Но для ультра-графония надо unreal engine ставить, правильно?
Да
Unreal работает только на C++?
Rust или Python для разработки там нельзя применять?
> Unreal работает только на C++?
Да
> Rust или Python для разработки там нельзя применять?
Скорее всего для тебя ответ нет.
Но вообще прикрутить нативные либы можно - но я могу себе представить код на расте в анриле только если у тебя на расте ецс и он заебись и ты уверен что оно тебе надо, а анрил теюе нужен иолько для вывода графона и редакторов.
Но само собой придется писать какую то либу чтобы это все соединить.
Но в разумности этого варианта я сомневаюсь, скорее всего нихуя нету какого то заебись фрецмворка нк расте который оправдает все эти лишние трудозатраты.
И скрипты на питоне тоже можно, подключаешь интерпретатор, пишешь какую то систему которая будет определенные скрипты вызывать и что то в анриле делать, и поехал.
Хз какие у тебя цели и что именно ты собираешься делать, с 99% шансом это все не нужно и стоит брать С++.
>Bgfx например и еще что-то такое.
>>1085154
>sokol https://github.com/floooh/sokol
авторы страдают какой-то херней и пишут свои парсеры шейдеров, при том что:
а) это бесмысленно - давно уже перешли на glsl
b) есть свой очередной универсальный синтаксис шейдеров (slang)- он хотя бы от офф вендоров, а не ноунеймов гитхаба.
плюс эта классическая болезнь - навернуть над одной функцией 10500 абстракций
>diligent engine
ооп головного мозга. там чуть ли не свой COM изобретен (нахуя, зачем).
>>1085164
>magnum graphics
это какой-то монстр из миллиона библиотек который хер знает как собрать.
>raylib
эти зачем-то упоролись в синтаксис opengl 1.0 и зачем-то сделали эмулятор begin/end на котором оно там внутри все костылит. (но вроде бы это было потому что рейлиб создавал преподаватель для студентов)
идейно да, это наиболее близкий пример, но им надо взять и все переписать с нуля
>потому что это, во первых, будет не оптимально, а во вторых, недостаточно, так как нужны материалы и тд.
за оптимизацию должна отвечать система сцены а не рендер.
так-то 2д тоже как бы требует оптимизации - например батчинга, и пользователь его сам пишет.
в 3д таки нужно только две вещи
- послать данные о ресурсах
- настроить конвеер
в принципе современные апи так и работают - настраиваешь командный буфер и запускаешь.
>нюанс в том, что 3D pipeline намного сложнее.
а вообще есть например Three.js и бабилон под браузеры. по сути минимальные обертки на которых можно делать 3D игры не ебясь со всякой лоу херней. вот такую бы вещь на десктоп и желательно на C++
>что насчёт Google Filament?
подобное страдает нечитаемым синтаксисом
(всегда забавляло, все эти гуглы так дрочат на собеседованиях, но самый упоротый код, это код от айти гигантов)
и лишней раздутостью - когда делает вроде мало, а по объему кода больше чем какой-нибудь UE
>Three.js
это граф сцены
>>1085293
>желательно на C++
https://github.com/OGRECave/ogre
в веб есть ниша для простых интерактивных 3D страниц. а вот целесообразность графического полу-движка предоставляющего только граф сцены крайне сомнительна. это уже пол движка, и лучше уже добавить остальные системы, чтобы сделать нормальный движок со всем интегрированным. иначе у тебя в движке будет свой граф сцены/ECS, которому надо как-то взаимодействовать со сценой граф движка, это только все усложнит.
>и лучше уже добавить остальные системы,
проблема в том что остальных систем много. и вместо уютного маленького движка получаем очередную попытку сделать юнити в подвале
если нужен полноценный движок - есть UE, есть юнити, есть годот, там валв кажется оживляют свой движок. крайэнджин еще. даже движ от фалко.
Все одно, одиночка физически не сможет все написать. Плюс его приоритеты задач могут не совпадать с потребностями пользователей.
При этом для многих инди игр эти системы не нужны. Часто для игры может требоваться только совсем минимум - модельку с текстурой вывести, да музон пробренькать.. не надо рассказывать про тыщи кода для частиц и PBR материалы бога...
вот типа wizordum - вывести кубик с натянутой текстурой, вывести билборды. Все - руби бабло. (хоть он и на юнити, но и для своего движка не много надо)
для этого даже не нужно библиотеку, куб можно сделать за неделю на opengl. ну или сойдет raylib. а вот для полноценного 3D движка хотя бы уровня road to vostok этого уже будет недостаточно, если одиночка не может сделать движок, то ты в одиночку тем более не сможешь сделать это поверх простой библиотеки.
Есть сейм. Но есть и плюс - годот воспитывает смекалку, как обойти все пропукно-гиблые места и релизнуть игру без пропуков.
>для этого даже не нужно библиотеку, куб можно сделать за неделю на opengl.
можно... но тут включается режим движкописи - начинаешь писать те самые ненужные для куба системы.
>>1085300
> хотя бы уровня road to vostok этого
инди игр требующих хотя бы такие технологии всеже не много.
а вот игр с кубами, спрайтами и т.д. даже в 3D - много делают.
без движков. как раз тут опять ковыряю обертку над openGL
такую игру надо было 10 лет назад делать, а сейчас это будет интересно только тебе (хотя сомневаюсь что это будет интересно даже тебе).
лучше делай road to vostok на ezEngine.
>визордум
выглядит как игры на FPS engine, которые на делали на ТВГ
>такую игру надо было 10 лет назад делать,
1) такие игры делают и сейчас. этот визордум в прошлом году релизнулся. и это не какой-то уникум - их там сотни
2) это можно пробовать осваивать в браузерках - все одно это сейчас единственный способ продать игру без пердолинка с казашкими счетами. посмотрел бы я - как ты запустишь road to vostok в хроме.
3) простота графония позволяет делать огромные миры не ебясь в сложные темы - даже тупо выводя в лоб километры пространсва, оно наверное будет работать без байтоебства
4) вон еще всякие хайтелы выходят.
>простота графония позволяет делать огромные миры
позволяет, но зачем? ты заранее исходишь из пораженческий позиции неудачника, который уже сдался. никому не будет интересно то, что ты будешь делать.
>позволяет, но зачем?
ну моя мечта - сделать что-то типа дагерфола - с гиганским живым миром.
так что графика может быть обманчива, и игру с 3D графикой может быть даже проще сделать.
>morrowind. пустая карта из 3-х ассетов с одинаковыми врагами и ящичками с инвентарями
И да и нет. Сейчас как раз прохожу её. По ощущениям, как недоделанная готика, статичный мир, огромный и сука пустой, я перед этим конченную готику 3 прошёл вдоль и поперёк, но даже там мир был более насыщен.
Графически с одной стороны небо, отражения, погодные условия с другой стороны поворот модели - вектор без умножения на скорость, это конечно лютый зашквар когда видишь, нпс который поворачивается мгновенно то в одну то в другую сторону.
Идиотское ограничение по весу инвентаря, при том игра заточена на бесконечные данжи и накопление лута.
Единственно что вытягивает эту игру это система прокачки, но это скорее для аутистов готовых сотни часов тратить на прохождение однотипных данжей, в желании стать самым сильным в этом мире.
Морровинд сильно переоценен, что тогда, что сейчас, огромные пространства и открытый мир нафиг не нужен если он пустой и однотипный.
Однако в производстве это оказывается проще, чем придумывать всякие интересные механики и геймплей.
Свитки никогда не были парком аттракционов, это сборник квестов где рпг это базовый набор механик чтобы эти квесты проходить/находить.
>поворот модели - вектор без умножения на скорость
animation based combat это рак для рпг, но мы живем в выросшем поколении дарксоулс-даунов и их искаженном понимании что такое рпг вот и имеем что имеем
Времена моровинда это когда всякий сахарок вроде анимированного вращения как в арпг/зельде был ненужон/считался дурным тоном консолепидорства
> там придумывать колоду способностей, балансить, и тд.
но ведь это и есть разработка игры. перенести это на движок это дело техники
я в последнее время делаю прототипы на бумажных карточках - обычных разрезанных листах бумаги, прежде чем начать что-то программировать
>это конечно лютый зашквар когда видишь, нпс который поворачивается мгновенно то в одну то в другую сторону.
Ты дотер что ли? В лиге легенд тоже поворот мгновенный, и ниче, турниры устраивают
> В лиге легенд тоже поворот мгновенный
Ты конечно сравнил кибердрочилью с видом сверху с рпг от 1 или 3 лица.
да, но новички обычно думают, что если простая графика, то игру просто сделать, а если сложная - то сложная. и попадают в ловушку, когда пытаются без опыта сходу сделать сложную абстрактную игру, или, что еще хуже, придумывать новые идеи для своей пиксель арт игры.
> клон
> придумывать
А нахуй придумывать, если можно просто скопировать и ретекстурить?
>>фича на уровне самого видеочипа
>Впервые слышу о подобном
Я особо этим не интересовался, но вот:
https://en.wikipedia.org/wiki/Tiled_rendering
Это причина эффективности мобильных GPU.
Это не то. Это оптимизация render target'ов, которые требуют большую пропускную способность памяти, особенно для deffered рендера, который копирует сразу несколько render target'ов. Экранчик делится на клетки, у каждой клетки свои локальные микро буферы для render target'ов в быстром кеше.
Классная тема, где скачать? Подойдет для игры про swin hater
https://www.youtube.com/watch?v=kJtOHNXjP90
Покупать видяху по цене самолёта, чтобы тени не шумели, я хуею.
И это даже не UE5, хотя тени там такие же всратые.
Я к тому, что зачастую не в движках дело, а в рукожопых разрабах.
> Я к тому, что зачастую не в движках дело, а в рукожопых разрабах.
Ну сделай как надо, покажи всем, раз самый умный.
Разработка игр это довольно сложный процесс, так, к слову.
Разве анрил не запекает статические меши автоматически? Этот шум видимо особенность люмена, возможно только на лоу оборудовании. Я запускал в ue5 обучающий контент от эпиков на 1660 там такая же фигня и мерцание.
На ue4 такой фигни не было..
на запеченку давно положили хуй в ААА
жрём уродливые тени в полностью статичных уровнях
Не так уж давно. Крайтеки ещё 10 лет назад положили. А современный гейдев только пришел к этому. И это ещё при том, что половина не умеет ни в pbr, ни в pbs. Так что мылу и уродливым текстурам ещё долго быть.
Ну просто интересно насколько приятно не делать игры на s&box
Проприетарное говно от мразей, разрабатывающих очередное казино для детей. Ничем не лучше ezEngine.
Рим не сразу строился. Вот PVKK выйдет и... Посмотрим че будет. Хотя для PVKK я думаю годо хватает с головой.
Почему жалко? Я тоже положительно относился к движку, пока не узнал лучше что такое роблокс, и чем занимаются разработчики sbox.
В их движке нет ничего особенного, чтобы зацикливаться на нем. Довольно паршивый, посредственный движок надо сказать.
>PVKK
Не удивлюсь если там фейковые скришоты из юнити, лол. Как для road to vostok.
Эта картинка иллюстрирует еще одну проблему современных движков - HDR рендеринг. Тусклые цвета, низкий контраст, как будто серый фильтр поверх изображения. Это происходит из-за того, что картинка рендерится с 32 битными цветами на канал, а потом сжимается с потерями до 8 бит. У разработчика нет никакого контроля как будут выглядеть цвета в его игре.
Ты даже близко не понимаешь о чём ты говоришь и насколько ты не прав. Возможно, если бы ты хоть пару раз запускал современные игры или современные движки, ты бы не писал такие глупости.
А может это ты не понимаешь? HDR рендерит выше отображения диапазона sRGB, и чтобы это отобразить картинка прогоняется через фильтр который по опеределнию все усредняет. Это типа аудио фильтра, который усредняет звук, делает его плоским. Так и HDR рендер после tone mapping фильтра становится плоской, имеет специфический вид ААА слопа >>1085673
https://modelviewer.dev/examples/tone-mapping
>Основная проблема, о которой сообщают пользователи электронной коммерции в отношении тонального отображения ACES (и даже AgX), заключается в значительной потере насыщенности. Многие художники были разочарованы невозможностью получить желаемый цвет продукта (как правило, продиктованный маркетингом) при любом сочетании свойств материалов и освещения, но мало кто понимал, что именно функция тонального отображения является ограничивающим фактором.
Пиздец ты дебилиус. Ну, нет, всё абсолютно не так, ты по верхам слов нахватался и не знаешь, что они значат.
Говоришь про нет контроля, потом говоришь про тонемаппинг. Так есть контроль или нет? Определись. А лучше сам потыкай чтобы не позориться.
Говоришь про sdr потом про SRGB потом про HDR - это не совсем связаннве понятия деб, ты наверное хотел сказать про SDR.
Ну и шиза про отсутствие контраста это шиза, игра будет весь твой цветовой охват юзать, то что у тебя на скрине это вообще дешевое освещение 10 летней давности без GI(и его имитации доп источниками - в кат сценах часто так делают) вкупе с грязными текстурами(что является стилистическим решением а не ограничением), а не цветовой охват и не контраст.
Хз просто попробуй хотя бы игры какие то запустить и ткни в пиксель где там они че усредняют
Он уходит c UNITY на REDOT
https://www.youtube.com/watch?v=htr2rPGYTdM
https://www.youtube.com/watch?v=2fQUlka0moc
Такую "насыщенную" графику потянет даже тройка. в браузере
Ты никогда не сможешь создать такую насыщенную графику нигде.
Ну тоесть формально проблема только в том что юнити слишком сильно дружит с сервером лицензирования, и из-за этого чел начал лезть в залупу годот. Нет проблемы с лицензированием, нет проблемы с самим движком, тупо техническая проблема с хабом, и надо просто все удалить и поставить назад. Ну ладно бы я еще понял, если бы чел свалил по идеологическим причинам, тогда выбор годота был бы оправдан, а так чел просто решил самоубиться каналом с юнити аудиторией и попутно удариться головой о все проблемные места годота (а их пиздец немало).
11 лет потратил на юнити, и, вместо создания своего движка, решил взять годот, да не просто годот, а какой-то форк? диагноз: дебильное слабоумие.
Надо чтобы он заценил видео хрюкающий-волк.мп4. После этого выйдет видео "Я возвращаюсь на юнити."
Все лучше чем биться о проблемы юнити. Которых больше 70 тысяч только публичных, пиздец!
>11 лет потратил на юнити,
>диагноз: дебильное слабоумие.
Факт.
>Я возвращаюсь на юнити
Спасибо, не надо. Там зависший пропук.mp4
Буквально TailQuest
https://godotengine.org/showcase/tail-quest/
Ты совсем ослеп? Видно что на пост процессинге выкрутили контраст. Само изображение тусклое. Из-за PBR все в какой-то белесой дымке.
стандартный PBR+HDR пайплайн совершенно не подходит для стилизованных игр.
Это вопрос рендер пайплана оптимизированного под фотореализм.
какая мразь, эффект френеля что ли?
а в реальности он тебя не беспокоит?
срал в горло этой мрази
карты нормалей тоже я её рот ебал
То, что здесь изображено >>1085739 далеко от реальности, мягко говоря.
И это в любом случае грубая имитация, без полноценного рейтресинга никакого PBR реализовать нельзя.
Оно просто обесцечивает половину картинку там, где должно быть затенение.
так эффект френеля должен зависеть от источников света а не светиться от балды в любом месте
по сути он нужен чтобы рисовать блик разной интенсивности, который усиливается при уменьшении угла камеры к поверхности
https://github.com/clockworklabs/SpacetimeDB
Да, но проблема в том, что в стандартном пайплайне всех движков это просто рисуется в шейдере как обесцвеченные пиксели в зависимости только от нормали. Без рейтресинга по другому не сделать.
Поразительно, как ААА приучили игроков терпеть эти уродливые артефакты >>1085787
>Без рейтресинга по другому не сделать.
это если ты вздумал рефлексы рисовать этим эффектом, а надо только прямой свет
>>1085794
что мешает взять блик по фонгу и добавить ему угол нормали к камере в кач-ве силы? я 100 лет назад такой шейдер писал и всё нормально было
>ААА приучили игроков терпеть эти уродливые артефакты
приучили не ААА, а конкретно юнити с говнорендером
про годот не упоминаем, т.к. графонистых игр на нем нет
>графонистых игр на нем нет
И не будет. Поскольку рендер в нём хуже чем в хрюнити
>Поскольку рендер
Не сколько рендер, сколько реализация 3д в целом. Годоту до 3д ещё расти расти. А там гляди может кто-то захочет Bakery адаптировать хотя-бы под годотю. Разраб плагина только за, только желающих не нашлось до сих пор.
это не так
нода это узел графа, а компонент - элемент линейного списка
нода избыточна
Ноды хуже компонентов. Единственное, когда они нужны - это иерархия, типа GUI, или скажем персонаж у которого оружие крепится к руке, а рука поворачивается. Обычно же у тебя есть домик, а в нем лифт, а в нем кнопка. Но нет такого, что лифт внутри другого лифта, а тот внутри третьего лифта, а тот на четвертом лифте и так далее. Хотя, если в лифте туррель, то может быть полезно
>лифт внутри другого лифта, а тот внутри третьего лифта, а тот на четвертом лифте и так далее
украл идею для ТВГ
>а конкретно юнити с говнорендером
ну толи дело игры до 2005 года - заходишь в сарай, и смотришь на квадрат малевича или там ищешь негра в темном-темном месте темной-темной ночью
помню doom 3. агась
юнити тут вообще не при чем - просто все перешли на srgb - который вообщет драйвером видеокарты включается. toon maping - это наследие предков там, где еще фреймбуфер создается в линейном пространстве, а не srgb
>хуже компонентов.
ну хуй знает. все говорят что компоненты - это про оптимизиацию.
но вы видели что внутри типичного GetComponent? это же сука перебор всего массива при каждом обращении (даже если бинарное дерево с хешем). Это же миллионы подобных переборов.
а полиморфизм? что системы, что компоненты - virtual и сразу нахуй 20% производительности (компилятор не умеет оптимизировать динамические вызовы - он же блядь не знает что там зовется)
стоит ли это кеш фредли таких выебонов?
А со стороны геймдизайна - вот говорят - это такой конструктор. но дизайнер не работает с деталями лего. дизайнер работает с орками, гоблинами, сундуками, а не с "нечно двигающееся", "нечто рисующееся", "нечто брянкающееся", "нечто скриптующее".
А внутри кода в секунду времени вообще хуй поймешь - кто там сейчас неправильно двигается- оно же блядь там абстрактно все работает
> это же сука перебор всего массива при каждом обращении
А ты не делай много таких запросов, не засовывай их в апдейты и всё будет норм.
Ну так никакого гет компонента быть не должно конечно, должен быть только перебор foreach. И вот уже пгчти ecs.
И то, и то - объекты. Нет никакой разницы добавлять их в список компонентов или дочерних объектов. Компоненты это лишняя абстракция, на мой взгляд.
Нет разницы между
var x = this.gameObject.GetComponent<Foo>();
и
var x = this.parentObject.GetChild<Foo>();
я не могу придумать сценария, где компоненты бы выигрывали.
У нод лучший UX в редакторе, на мой взгляд. Их все видно в иерархии, иерархию удобнее редактировать.
>>1085861
>но вы видели что внутри типичного GetComponent
Это только в юнити, который позволяет компоненты одного и того же типа вешать на один go. Но это не значит что ты обязан использовать этот механизм, ты можешь после инциализации и связывания монобехов в твою архитектуру вообще не использовать GetComponent, а искать их инстансы твоими собственными архитектурными способами. К тому же в юнити есть ecs, и в нем уже такой проблемы нет.
>virtual и сразу нахуй 20% производительности
Аналогично в годоте, методы лайфтайма ноды тоже являются virtual и переопределяются реализациями, и это невозможно пофиксить. Но если тебе реально важны такие копейки - мне не понятно нахуя тебе вообще нужна графовая сцена, пиши как деды завещали и сам считай все матрицы.
>А со стороны геймдизайна - вот говорят - это такой конструктор. но дизайнер не работает с деталями лего. дизайнер работает с орками, гоблинами, сундуками, а не с "нечно двигающееся", "нечто рисующееся", "нечто брянкающееся", "нечто скриптующее".
Дизайнер работает с подготовленными программистом префабами, а то и вовсе собирает по кускам модели, анимации к моделям, vfx, выдает программисту вместе с концептом, программист настраивает, а дизайнер затем еще и шлифует. Ему поебать абсолютно, компоненты там, полноценные реализации, вплоть до того что дизайнер может вообще не видеть что это наборы компонентов, а просто наблюдать их набор полей, потому что в юнити или в годоте ты можешь полностью переопределить как редактор "видит" твой обьект. Я например с помощью этого механизма починил главную проблему нод - 1 нода - 1тип - 1скрипт, и теперь могу реализовывать рантайм композицию группы сцен в рамках 1 ноды, внутри которой может жить от 2 до бесконечности скриптов разных типов с разными задачами.
>А ты не делай много таких запросов, не засовывай их в апдейты и всё будет норм.
ну например в юнити допердолились до того что вообще отказаться от архитектуры движка и пердолить все на своих классах, с одним GameObject на сцену.
>>1085866
>Ну так никакого гет компонента быть не должно конечно, должен быть только перебор foreach. И вот уже пгчти ecs.
тебе надо подвигать из внешнего скрипта (какого-нибудь луа для дизайнера) орка в новую позицию.
>реально важны такие копейки
это не копейки. 20% это реальная цифра потери производительности за виртуальные методы.
>>1085868
>ноды тоже являются virtual
не знаю как в годоте, но прелесть оопшных нод в том что вместо наследования и полиморфизма можно юзать агрегацию - не теряя производительность.
>>1085868
>Дизайнер работает с подготовленными программистом префабами
вообще почему-то в современном мире дизайнеров появилось мнение, что это какие-то инвалиды не способные нажать две кнопки. А это не так. достаточно посмотреть инструменты ААА игр - чтобы понять что геймдизайнеры там ебошат в скриптах не хуже кодеров.
имхо, разница между геймдизайнером и программистом - программист ебется за оптимизацию и качество, а геймдизайнер, за логику выполнения. Но по сути код пишут оба. просто один пишет код на каком-нибудь С++, а другой на нативном языке.
нода (объект сцены) и компонент (свойство объекта) - разные уровни абстракции
то что годот не позволяет более 1 компонента прикрепить к объекту заставляет пукать десятками нод вместо одной, но это не норма
>не знаю как в годоте, но прелесть оопшных нод в том что вместо наследования и полиморфизма можно юзать агрегацию - не теряя производительность
Теряя, если это не laba2.cpp. Любой более менее сложный продукт на базе агрегации либо перейдет на контракты(интерфейсы), либо будет вынужден писать сложную макросную логику, чтобы заменить ею контракты на компайлтайме. Контракты обойдутся еще тяжелее чем виртуальные методы, ебля с макросами - ну такое себе наверное может позволить только убейсофт.
зачем? вообще в этом разговоре есть ключевая ошибка - многие рассуждают о какой-то абстрактной машине абстрагированной от всего. отсюда и рожают всякие абстрактные машины с мыслью "а вдруг потом понадобится добавить ХХХ".
в реальности так никто не делает. В реальности у тебя есть четкий диздок, есть сроки, есть согласования, и переделка логики часто недопустима. А если что-то нужно переделать - то это конкретный, документируемый процесс - в котором код - это вообще самая мелочь, все начнется с бюджетов
поэтому у тебя на начале игры уже должны быть все основные классы (это кстати сразу пишется в тех док). И из этого уже строишь всю архитектуру - и тебе не нужны все эти расширения.
если проще - вот ты делаешь игру змейка в 2д. ты не можешь ее делать с принципом, а вдруг через месяц это будет игра про кота, а вдруг она будет в 3д, а вдруг надо не собирать яблоки, а убегать, а вдруг это вообще будет карточная игра... а нет, это будет шутер.
(если ты делаешь по такому принципу - у тебя вообще никакой игры не будет)
То есть у тебя четкое понимание игры, в нем есть четко - змейка, яблоки, поле. три класса. возможно будут варианты (ядовитые яблоки, камни, гемы) - но это экземпляры классов. И тебе не нужны никакие ооп, ексы и прочая лабуда.
---------------------------------------------------------------------------------------
в екс и подобное должны дрочиться движкописи - они вот как раз не могут знать - какой будет игра, какие в ней будут требования и т.д. Но много ли движкопись готовых отдать жизнь за никому не нужный клон годоти?
Художник делает игру с принципом - да ебись оно как угодно, я не прогер, там-сям надергаю скриптов из интернета и норм (сейчас еще им в помощь вайбкодинг)
короче, они ебашат игру. им насрать. И потом говноблогеры высирают видосы про то, какой же там ужасный код (например про разраба яндере) - но вот только на этом ужасном коде есть игра, а вот у них....
А программист начинает - а вдруг у меня будут не орки а спейсмарины, а вдруг не шутер, а стратегия, а вдруг... Надо все делать по уму, обмажусь в ексы, сделаю все абстрактно, чтоб как конструктор. А игра где? а игры нет - прогер прогает миллион компонент и систем на все случаи жизни (только чьей?)
>а искать их инстансы твоими собственными архитектурными способами.
во, щас смотрел одну реализацию. там GetComponent выполняется по индексы за O(1).. было бы заебись, если бы не то что в итоге энтити хранит указатели на все существующие виды компонент. Вроде по сути 4 байта, но...
немножко математики - если в игре 100 видов компонент, и 10к энтити, то это уже 4мб оперативы только на то чтобы GetComponent работал без оверхеда. для пу мож и похуй, а для браузерки жопа
>А программист начинает - а вдруг у меня будут не орки а спейсмарины
так будет делать плохой программист, про это даже была древняя статья "как программисты пекли хлеб"
>>1085880
>вообще знаете почему дизайнеры/художники чаще релизят игру
нет, не знаю. а что если я одновременно художник и программист? перфекционизм присущ любому независимо от специализации.
вот дорисовал я все спрайты персонажей, ура. а потом вижу, что бэкграунды для них не подходят. перерисовал бэкграунды, но пока рисовал, так прокачал скилл, что персонажи стали выглядеть убого. потратил ещё полгода и перерисовал персонажей. вроде всё нормально, но оказалось, что они совсем не вписываются в изначальный концепт и стиль игры. и т. п.
>в реальности
У меня например в реальности есть 4 типа никак не связанных логически, но требующих связки геймплейно сущности - физика машины, скин этой самой машины (модель, материалы, коннектпоинт для турели или другого обьекта), турель на машине (модель турели, материалы), эмиттер проджектайлов турели (с настройками и разными скинами проджектайлов). И всю эту хуйню надо уметь увязывать друг с другом, при чем, количество турелей определяется скином машины (так как связаны прокачкой), а физики может быть 2 (колеса, воздушная подушка), что помимо прочего накладывает связь взаимодействие физики + скин (сопла подушки визуально дуют в разные стороны в зависимости от направления движения и эта информация берется из физики). Я не представляю, как это можно вразумительно и в человеческие сроки связать без наследования и без полиморфизма. Агрегация ли, композиция ли - обе потребуют контракты-виртуальные методы. Ecs все это дополнительно усложнит, так как не использует полиморфизмом.
> Я не представляю, как это можно вразумительно и в человеческие сроки связать без наследования и без полиморфизма. Агрегация ли, композиция ли - обе потребуют контракты-виртуальные методы
зачем ты это передаешь абстрактным классом? у тебя есть конкретные типы - передавай и храни их.
>у тебя есть конкретные типы
Ну есть у меня конкретные типы, дальше что? Мне их методы вызывать как прикажешь? If object.instanceof(Mytype) { objecs as Mytype.Call() } ? Ну ладно, эту проблему частично решили в c# 15 с вводом union types, но эта версия языка еще даже в стейбл не вышла.
раньше писали игры на Си и не бухтели
ты всегда можешь найти исходный код какой-нибудь старой игрушки на Си, где будет достаточно абстракций штатными средствами
>раньше писали игры на Си и не бухтели
К сожалению в марио из 98 в 2к26 играть никто не будет, большее я не вытяну в одно лицо даже со всеми нейронками
марио из 1985 года, а в 90-ые ещё вовсю писали на си, а это в том числе весьма сложные стратегии и рпг с разными сущностями
не поленись почитать код, там подходы вроде if (enemyType == ORC) {attack(g_player);} присутствуют
обычно там везде лютое спагеттище процедурное, которое чудом работает и отлажено болью и по́том тысяч программисточасов
>в 90-ые ещё вовсю писали на си, а это в том числе весьма сложные стратегии и рпг с разными сущностями
Это писали крупнейшие по тем временам студии, где трудились десятки программистов фуллтайм.
Компоненты - это просто идиома юнити, как создавать и получать ссылки на объекты. Реализация объектов в обоих движках может быть идентичная, просто различаются идиомы получения ссылок на другие объекты сцены (мой пример с GetChild() >>1085867)
Например, в unity ты создаешь GameObject игрока, добавляешь ему CharacterController и MonoBehavior со скриптом. В скрипте ты дергаешь ссылку на контроллер и вызываешь метод, а контроллер дергает game object и изменяется трансформации.
В godot так же можно создать корневой объект и добавить ему 2 дочерних объекта с контроллером и скриптом, никакой разницы. Но в случае узлов можно еще "схлопнуть" несколько различных объектов в один, сделать наследование Player -> CharacterController -> GameObject, тогда вместо того, чтобы прыгать по нескольким ссылкам для обновления, нужно прыгнуть по одной ссылке. Это эффективнее и с точки зрения производительности, и с точки зрения памяти (меньше объектов, а меньше объектов - эффективнее GC).
во-первых, компоненты были задолго до юнити, во-вторых - компоненты тоже можно наследовать
у тебя что ли мозг съеден годотом
сейчас это можно переложить на нейронку
>>1085890
да чаи они там гоняли, лоботрясы
тем более штат ААА-компаний 90-ых по нынешним меркам просто смешон, человек 20 включая маркетологов и директоров
Сейчас у процессоров большие L3 кеши, поэтому даже с оптимизированным ООП можно достичь производительности уровня ECS.
Причем здесь годот. Я просто сравниваю систему с компонентам и пытаюсь понять, есть ли в ней вообще смысл (пока я не нашел).
>сейчас это можно переложить на нейронку
нейронка как раз моментально запутается в спагетти
ей нужна хорошая изоляция
ну подумай, с точки зрения проектирования и ООП: червяки которые у тебя по экрану ползают - это игровые объекты (сцены), объекты первого порядка
а ихние спрайты и коллайдеры - это свойства объектов. коллайдеры сами по себе по сцене не ползают
игровые объекты могут быть частью дерева сцены, если оно у тебя в движке есть. а если нет, то это просто список сущностей.
схлопнуть игровые объекты и компоненты в одну сущность - технически можно, но нелогично, это создаёт противоречие между логикой кода и логикой дизайна. мол тут у нас написано так, но вы это игнорируйте, потому что в коде у нас иначе
можно сделать ещё шаг назад и отказаться от композиции вообще, тогда твои червячки - это что-то, что наследует класс Sprite, потому что оно видно на экране. но тут возникают сложности, когда нужно будет наследовать разные комбинации
значит надо подождать 1-2 года, пока не наступит AGI
а пока пиши спагетти вручную
>а ихние спрайты и коллайдеры
Их необязательно добавлять в список "компонентов" и вызывать GetComponent чтобы получить на них ссылки.
Композицию так же можно сделать через добавление дочерних узлов.
это уже ненужный костыль, который вызван нитакусичностью
компьютерная игра - это моделирование какой-то реальной игры. либо настольной, либо физической активности
если у тебя в коде "мячик", "текстура мячика" и "звук мячика" - сущности одного порядка, то ты обосрался с проектированием
а ты обосрался с проектированием потому что не занимался моделированием бизнес-процессов, вот и думаешь что в разработке игры ты можешь делать абсолютно что угодно, а это не так
Я думаю лучший вариант где-то посередине. Например, было бы лучше если в unity MeshRenderer, RigidBodt и т.д. наследовались от GameObject, а скрипты были бы компонентами.
>всплывающие сообщения, по типу HTML
так это не часть игрового мира, другой домен. моделировать его объектами сцены и компонентами не надо
почитай книжку типа domain driven design
Что за безумную шизу я прочитал? Зачем наследовать го? Зачем сенд меседж?
дед Алан Кей завещал, что истинное ООП - это обмен сообщениями между объектами
но анончик похоже просто нахватался по верхам юнити и годота и хочет сделать свой идеальный движок
Компоненты могут эффективнее так как даже если по итогу объектов создается больше, то в среднем они занимают в 3-5 раз меньше памяти, то есть это будет эффективнее для кеша.
Мне просто интересное, как подход НАУЧНО лучше, в юнити или годоте.
Сначала нужно выаести определение, что значит "лучше", а уже потом что-то думать.
это не наука, а бизнес, поэтому лучше - это с наименьшими затратами
>вообще знаете почему дизайнеры/художники чаще релизят игру в стим, чем одиночки программисты
Потому что главное в игре это визуал. Приятная картинка радует глаз и привлекает игроков в виши. Уже на этапе разработки появляется группа поддержки, обсуждения какие-то. Поэтому даже у автора вырабатывается достаточно серотонина для того, чтобы продолжать разработку.
А у прогромиста вишей никаких нет, потому что до последнего стыдно и нечего было показывать. Два куба-заглушки на скриншотах и 3 видеоролика с разбором гениального кода на два часа посмотрело 2 инвалида и поставили 1 дизлайк. Отсюда нулевая мотивация продолжать игру. Поэтому игра века забрасывается превращается в ЭТО ПРОСТО ДЕМКА МЕХАНИКИ, ВЫ НИПРАВИЛЬНО ПОНЯЛИ!
Картинка != игра, так что не пизди. Ни художник, ни программер, ни 3д артист, ни музыкант не являются игроделами. Это вспомогательные роли которые существуют и без игр. Только геймдизайнер является чистым игроделом.
>Это вспомогательные роли которые существуют и без игр
Речь в посте идёт об одиночках, поэтому ты спизданул хуйню уровня "Только режиссер ялвяется чистым киноделом"
Ты увидел несколько игр в стиме сделанных художниками, и решил что художники что-то там лучше заканчивают. Я могу так же найти примеры игр сделанных программистами. То же tangy td, сделанная программистом на своем движке.
Заканчивают игры только те, кто их делают. И я скажу так, что у программиста шанс закончить игру несравненно выше, по ряду причин. Во первых, у него будет большой опыт разработки игр. Во вторых, у него будет системный подход к разработке. Для того, кто 5 лет делал движки, потратить еще 1 год на разработку - это само собой разумеющееся. Для новичка без опыта, год - это беконченость, и поэтому большинство таких разработчиков бросают свой проЭкт через неделю-две.
>Во вторых, у него будет системный подход к разработке
задрачивание в ексы, правильную архитектуру, и прочие высшие ценности - не способствует завершению игры
>>1085959
> я скажу так, что у программиста шанс закончить игру несравненно выше
если бы было так - в этом треде бы уже десятки игр сделали.
>>1085959
> Для того, кто 5 лет делал движки, потратить еще 1 год на
нет, он потратит еще 5 лет на идеальный движок.
>>1085959
>Для новичка без опыта, год - это беконченость,
сейчас тебе вон нейронка за час основу любой игры напишет. художник просто нарисует туда моделек/текстур и в релиз
А программист... начнет переписывать код
>шанс закончить
Тут дело даже не в шансе. Художники сильно ограничены в игровых механиках. Они максимум потянут совсем уже примтив. Поэтому они часто уходят во всякие новеллы.
Майнкрафт был создан программистом, который идеально владел кодом. В игре шикарная архитектура кода, грамотное использование паттернов без фанатизма. Естественно никакой художник такое бы и близко не потянул.
А в движкосраче не банят
Ворюша <<< ТВГшки << годотер < ньюфаготредер < уечер < юнитист < субшотер < девлогер < движкосрачер
> если бы было так - в этом треде бы уже десятки игр сделали.
Нет, 0 связи
> сейчас тебе вон нейронка за час основу любой игры напишет. художник просто нарисует туда моделек/текстур и в релиз
Где же твоя игра тогда?
Остаются только демки с обновлением положения у 100 000 боидов.
>ECS
придумали до юнити. одна из первых запруфанных игр на ECS (и важнее - презентация технологии) - dungeon siege. типа большой бесшовный мир за счет этого и сделали... типа без екс они бы не смогли сделать такой мир...
вот только в 2002 году также вышла готика, в которой также бесшовный большой (и намного более детализированный) мир. без всякой екс дрочи.
вот и думайте - одни дрочили во всякую хуиту, а другие "хуяк-хуяк и в продакшн" (готика на релизе неиграбельна была из-за багов). Хотя обе игры оставили свой след в истории... только доказывая что вся ебля с кодом бесмысленна.
другой пример - был дрочер кармак вылизывающий все до асемблера и вуду магии. а был суини которому ебать на эти ваши дрочи кода, он во все ооп больной (он юзал ооп в 86 году кста). Один сделал квейк. другой анреал торнеймент.
снова две великих игры, и снова показали что код - хуйня полная, что делай хорошо, что делай плохо - не он решит за игру.
>он юзал ооп в 86 году кста
кто не понял вдруг - бытует мнение что классическое ооп это медленно и нельзя в геймдеве. Особенно лет десять назад. (собственно отчасти дрочь на екс тоже растет отсюда, типа ооп медленно а вот DoD - это то что надо)
Так вот, Суини юзал то самое академическое ооп, как по учебнику, еще в своих первых 3д демо движка в 1986 году - все летало и было графонисто на моменты своего времени. И не просто ооп, а того монстра который с com от майкрософт смешано
первый ECS был в Thief the Dark project
это было сделано для удобства дизайнеров, можешь скачать редактор и посмотреть на композицию объектов игрового мира
такое уж место, там все друг друга опускают. и им нормально. петушатник одним словом. то ли дело здесь, атмосфера взаимного уважения и свобода слова.
Просто до сих пор бытует популярное заблуждение, что если в движке есть ECS, значит движок быстрый, и что нужно использовать ECS, потому что оно лучше. Некоторые даже на основе этого выбирают движок.
unity опять же, вложили 10 лет в говно ECS, вместо того, чтобы оптимизировать ядро движка. А по итогу обычный dotnet быстрее их супер оптимизированного burst. Потеха.
Интервью с бывшим разработчиком unity, который работал над HDRP.
Рассказывает, что они хотели модернизировать движок, но в unity много разных команд, в частности мобильная команда, которые не хотели этого. Он из-за этого впал в депрессию и уволился, после этого разогнали всю HDRP команду.
>у них единого видения что нужно делать
вот что бывает когда продукт захыватывают выблядские мобильные дегенераты верящие что создав движок для создания мобильного дерьмища они заработают лядрды
Я там редко пишу, годотеры меня не любят потому что я на хую видал gds и ноды, а мое решение проблем нод в годоте с интеграцией в редактор считают "неестественным", потому я серю в движкосраче и воюю на три фронта, как бывший юнитист, нынешний годотер и бывший и нынешний EC-дрочер
Тебе мобильный рынок мешает делать игры? Или в чём причина твоего пука.
Делай хорошие мобильные игры сам
У тебя каша голове. Ецс и берст это очень слабо связанные вещи.
Бёрст нихуя не медленнее .NET(который если что тоже супер оптимизированный при JIT), особенно в векторизации.
> Просто до сих пор бытует популярное заблуждение, что если в движке есть ECS, значит движок быстрый, и что нужно использовать ECS, потому что оно лучше. Некоторые даже на основе этого выбирают движок.
У тебя в голове бытует или где? Ецс это архитектурный паттерн с возможностью дод реализации(через спарс сет либо через СОА как в юнити ецс).
Например Entitas вообще не дод, это ецс фреймворк который вообще ни в какую производительность не метит, он чисто архитектурный.
> unity опять же, вложили 10 лет в говно ECS,
Нормальный ецс, пусть и сложный.
> вместо того, чтобы оптимизировать ядро движка.
Какое конкретно ядро, что конкретно оптимизировать? У них рендер и физика на берсте переписаны.
Чем собилки отличаются от не мобилок? Кроме того, что на мобилки требования к оптимизации куда выше.
> рынок мобильных игор приучает жрать говно по типу роблокса,
Пиздец.
Я бы понял если бы ты сказал говно по типу бегущего петуха, в котором геймплея около 0 и миллиард рекламы.
Но роблокс это буквально вин, вершина UGC.
> из-за чего атрофируются мозги уже с раннего возраста.
Какое нахуй атрофируются мозги, это олна из самых креативных игр при этом форсящая соц взаимодействие
>Остаются только демки с обновлением положения у 100 000 боидов.
Вот игра на Unity где применён ECS и он там реально нужен - Diplomacy is Not an Option, разрабы Door 407 (из России), это стратегия где тысячи юнитов на карте.
https://store.steampowered.com/app/1272320/Diplomacy_is_Not_an_Option/
это экстремистская игра, через неё вербуют террористы
а бегущий петух база
> это экстремистская игра, через неё вербуют террористы
Клевета
УЛЬТИМАТУМ ОТ UNITY
стек: ECS (UNITY DOTS) + компилятор Burst\IL2CPP + UNITY JOBS
Дрочим кубы, 100 000 кубов при 109 fps, вот и всё, кто так ещё сможет?
https://youtu.be/kKGiEz1enzw
>требования на оптимации
ЛОЛ. Там просто буквально кал, который грузится по две минуты и лагает. Там всем похуй на оптимизацию.
>чем отличаются
Да много чем, неудобность управления породила тупейшие казуалки, которые уже на самоподдуве начали вырождаться еще сильнее. Второе, ориентрированность на короткие сессии и постоянное прерывание рекламой.
Как же годот ебет...
Все так. Это нужно только для боидов. Остается только придумать какую-то интересную игру на боидах, это почти ни у кого пока не получилось, кроме унылых примеров тысячи юнитов набигают стенка на стенку.
> ЛОЛ. Там просто буквально кал, который грузится по две минуты и лагает. Там всем похуй на оптимизацию.
Ахаха, знаток в треде.
Ты в курсе что если у тебя игра вебгл и она грузится больше 5 секунд то она идет нахуй из стора?
В гугл плее если АНР(игра подвисла) больше 1% то ей режут органику?
А если игра жрёт много аккумулятора(=греется теелфон), то готовься к волне единиц в отзывах которые убьют органику.
Поэтому требования к оптимизации на мобилках очень высокие, особенно у серьезных игр, это я тебе могу сказать из практики - там реально на это много времени тратят.
То что слабо квалифицированный чел в целом может сделать гиперказуалку без йоба оптимизации - ну да, может, но ему все равно придется немного запариться и хотя бы гайды посмотреть несколько дней чтобы минимум сделать.
А вот инди на пк - это пиздец, вот там обычно во все тяжкие идут потому что железо мощное и о перегреве девацса думать не нужно.
> Да много чем, неудобность управления породила тупейшие казуалки, которые уже на самоподдуве начали вырождаться еще сильнее. Второе, ориентрированность на короткие сессии и постоянное прерывание рекламой.
Это конкретные жанры, это как говорить что пк говно потому что на пк можно в вебгл казуалки с рекламой играть. Ну да, можно, а можно и в другое играть. Как и на мобилках.
>Ахаха, знаток в треде.
>Ты в курсе что если у тебя игра вебгл и она грузится больше 5 секунд то она идет нахуй из стора?
>В гугл плее если АНР(игра подвисла) больше 1% то ей режут органику?
>А если игра жрёт много аккумулятора(=греется теелфон), то готовься к волне единиц в отзывах которые убьют органику.
Прохладные истории, вот только я ставил буквально игры из топ рекомендаций и там было все описанное мной.
>Это конкретные жанры, это как говорить что пк говно потому что на пк можно в вебгл казуалки с рекламой играть. Ну да, можно, а можно и в другое играть. Как и на мобилках.
Ну а это просто фантазии, может на десять тысяч говна там где то и есть нормальная игра, только хуй ей найдешь. Ну типа я видел пару шутеров похожих отдаленно на комп игры, ну так и они урезаны в разы управлением, всяким автоаймом и прочим.
> Прохладные истории, вот только я ставил буквально игры из топ рекомендаций и там было все описанное мной.
Прохладные истории. Поставил пару виральных топов которые в топ на неделю залетели спустя пару месяцев разработки и пока офк не успели получить полноценную оптимизацию.
> Ну а это просто фантазии, может на десять тысяч говна там где то и есть нормальная игра, только хуй ей найдешь. Ну типа я видел пару шутеров похожих отдаленно на комп игры, ну так и они урезаны в разы управлением, всяким автоаймом и прочим.
Идиотский аргумент. Я говорю - на мобилки есть сложные игры разных жанров. Ты говоришь - 1 на 10к.
Ну збс, на пк тоже 1 нормальная на 10к вебгл гиперкпзуального калыча. Отличный показатель.
Тут вообще не важно сколько, важно наличие и отжор рынка - какой-нибудь мидкор могут делать больше сотни человек с топ квалификацией годами, а гиперказуалку васян который только только курсы прошел в соло за месяц, офк из больше будет.
>Поставил пару виральных топов которые в топ на неделю залетели спустя пару месяцев разработки и пока офк не успели получить полноценную оптимизацию.
Играл и в игры которые существуют годами, та же хуйня. Никто и не пытался их оптимизировать. Да и вообще, это даунская отмазка - ведь они могли сразу сделать и выпустить оптимизированную версию.
>Ну збс, на пк тоже 1 нормальная на 10к вебгл гиперкпзуального калыча
Это где ты такое видел? Уже выдумываешь прямо на лету.
> васян который только только курсы прошел в соло за месяц
Говномобилки выпускают огромные студии. Васянов там практически и не заметишь.
Это GPU частнцы, compute шейдер, данные не покидают GPU. К архитектуре годот не имеет отношения.
Смысл этих тестов в том, чтобы обновлять игровые объекты на CPU стеке. Давай демку с одновременным обновлением 100 000 нод на годоте.
Ровно то же самое что и в твоей юнити дрисне, никакой логики там не происходит, просто частицы-кубы прыгают на месте.
Нет, в unity фреймворк игровых объектов на движке. В твоем примере один compute шейдер и один вызов графического API нарисовать миллион кубов инстансингом.
А в твоем видео кубы просто скачут и нет никакой разницы.
есть разница, ими код на C# управляет
дело ведь не в том, что они рисуются, а в том, что поведение обсчитывается
>ими код на C# управляет
Сразу кал. В годоте можно сразу на c++.
>дело ведь не в том,
Дело в том, что похуй где там обсчитывается, потому что в результате просто прыгают кубы.
А передавать положения объектов и анимации с CPU вообще не проблема.
C# с burst не медленнее C++
> передавать положения объектов и анимации
это для наглядности. можешь что угодно передавать.
ты не понимаешь, что суть демки не в отрисовке - можно вообще убрать отрисовку кубов и всё будет даже быстрее работать. но чтоб впечатлить обывателя типа тебя сделали видео с кубами. усёк?
В демке прыгают кубы, если бы они делали что-то сложнее, было бы что обсуждать, а так нечего.
Вот это сделано на годоте лет 6-7 назад: https://www.youtube.com/watch?v=HawWnuMn1mc
это демка не про кубы, а про ECS - кубы это просто визуализация для недалёких
но видимо до тебя даже так не доходит
Ты ничего своей демкой не доказал, кроме того что ecs подходит для скачущих кубов, но скачущие кубы можно делать и другими технологиями, проще и быстрее.
это не моя демка
обывателю она ничего и не доказывает, а специалисту понятно
Специалистам давно понятно что ecs бессмысленная вещь, поскольку нужна только для масштабов от 10000+ прыгающих однотипных кубов, что для геймплея в 99,99% просто не нужно.
>compute шейдер, данные не покидают GPU
А ты похоже и не специалист, раз думаешь, что прочитать данные из GPU после compute shader нельзя.
откуда ты знаешь, что думает специалист, ты же не специалист.
ты думаешь что с помощью частиц можно нарисовать монстриков, а с помощью ecs кубы. это показывает отсутствие абстрактного мышления что для программиста проф. непригодность.
на самом деле, ecs и burst в юнити вообще ничего не рисуют, они не для этого
С помощью частиц на годоте не просто "нарисованы монстрики", а существует геймплей, в котором там монстриков поджигают, отталкивают.
А в притащенной тобой демке на юнити просто скачут кубы.
Все что ты показал что ты аутист, который пускает слюни на синтетические тесты, но не понимает что они ни для чего не нужны.
ты можешь найти десятки демонстраций burst с гемплеем. где 10000 юнитов можно выделить рамкой и послать рубить друг друга, кубы это максимально упрощённая демонстрация для новичков. начни хотя бы с кубов
> 10000 юнитов можно выделить рамкой и послать рубить друг друга
Ну то есть есть буквально одно унылое применение, которое все повторяют.
Когда появится что то реальное, возвращайся.
Ты понимаешь что означает benchmark? Это просто тест сколько игровых объектов можно обновить из C#. Вместо простых кубов там может быть логика. А в compute шейдере не может быть игровой логики, это простой шейдер частиц, двигающий кубы по простой фиксированной логике.
>Вместо простых кубов там может быть логика
Ну вот когда будет тогда и приходи.
Тривиальная логика легко выоптимизируется и получается вырожденный код, который не показывает что будет происходить в реальности, когда ты попробуешь хотя бы 10 разных взаимодействий в ecs реализовать.
Ну так и говори, "да, в годоте нельзя обновить положение 100 000 узлов, но это и не нужно". А ты пытаешься доказывать, что gpu частицы это аналог ECS из unity и только компрометируешь себя.
> ведь они могли сразу сделать и выпустить оптимизированную версию.
Нет, это лишние затраты, нет смысла этим заниматься пока концепция не проверена - может вообще идея игры мертвая.
> Это где ты такое видел? Уже выдумываешь прямо на лету.
Все вебгл игры работают везде, на вебгл игра портируется элементарно - все кто делают легкие мобилки сразу на вебгл площадки льют тоже.
> Говномобилки выпускают огромные студии. Васянов там практически и не заметишь.
Лол. Нет. У меня точных цифр нет, но по вакансиям если судить - если студия большая то у них либо мид кор, либо большая казуалка(типа матч 3 обвязанного сотнями всяких систем, там и квеств, и баттл пассы и миссия и прочий кал), гиперкэж большие студии не делают.
Гиперказуалки делают либо супер маленькие студии, либо супер маленькие студии с издательством через какой нибудь азур или вуду, иногда числятся как их внутренние студии. И тех и тех много, и то и то это всё таки маленькие студии.
> Ты ничего своей демкой не доказал, кроме того что ecs подходит для скачущих кубов, но скачущие кубы можно делать и другими технологиями, проще и быстрее.
>>1086053
> В демке прыгают кубы, если бы они делали что-то сложнее, было бы что обсуждать, а так нечего.
Есть куча крутых игр в проде на ецс. И на юнитевском, и на кастомных. Также как и берст - его можно юзать и в комплекте с юнитевским ецс, и без(и это тоже не супер редкость)
По сути это бенчмарк оптимизированного пути для потокового копирования памяти CPU -> GPU, больше он ничего не тестирует.
Кстати, в D3D12 можно использовать REBAR для прямого копирования в GPU память, минуя временный upload буфер, это еще сильнее должно оптимизировать этот тест.
причём тут GPU? сколько раз тебе объяснять, эти сущности не обязательно должны иметь рендер компонент
В которых 15 игровых объектов и в которых ecs который показывает себя от 10000+ нахуй не нужен.
Зачем ты строишь из себя лоботомированного дурачка, забывшего в что годоте это делается через одну ноду - MultiMeshInstance? Ну можно еще аддон VAT анимации сверху навернуть, что собственно я в своих играх и делал
это не технология годота, это технология видеокарты
>>1086084
юнити выходит далеко за рамки графического движка
попробуй спроси у нейросети - зачем нужны burst, unity jobs, ecs, там много материала
> ноду
Ахааха бляя а вы знали что в годоте рейкат через ноду делается ч ет вспомнил ахахаха
>unity jobs
Зачем, если в C# уже есть встроенный ThreadPool?
не знаю, так положено
ты ведь всё равно не будешь их использовать
В годоте конечно есть нода для новичков, удобная для каких то разовых операций, но из скрипта есть удобный доступ прямо к физ.серверу через direct_space_state. Но если у тебя 100000 объектов, там естетственно уже другие оптимизации будут и не рейкасты движка, лол.
Впрочем, можешь показать конечно 100000 на своем юнити с берстом
Все, что не затрагивает системы движка и их производительность, вообще не имеет смысла обсуждать, потому что это тривиально реализуется самим пользователем.
Зачем мне ECS, я и сам могу массивы в цикле обновлять.
ECS актуально только за счет тесной интеграции в движок, без этого оно вообще не интересно.
рендер не единственная система движка, олсо твои сущности могут рисоваться в один момент, а в другой не рисоваться. или рисоваться каждая десятая и т. д. возможности безграничны, не нужно ворочать нос
Сейвовость(рид врайт контейнеров используемых смотрит), удобная совместимость с берстом
>твои сущности могут рисоваться в один момент, а в другой не рисоваться.
>или рисоваться каждая десятая
ecs жидко пукнет и умрет перестраивая индексы.
Я знаю, что никаких структурных изменений в этом не должно быть, более того у ецс есть разные варианты реализации, как дешевые для структурных измененийч так и дорогие.
ты чего-то по верхам нахватался и бормочешь про какие-то индексы
нет в unity ecs никаких индексов
тебе ли не всё равно, ты никогда не будешь их использовать
для твоей поделки на годоте это не нужно. я их тут видел как минимум три штуки, и они все одинаковые - моделька анимешной девки бегает по низкополигональному миру с хрюкающими волками, на этом разработка игры заканчивается
>тут
А я тут давно ничего не выкладываю. Зачем метать бисер. Главное игроки довольны.
Там у меня много чего, самолеты летают, корабли плавают. А двощерам да, достаточно анимешную девку побегать дать.
Ну смотри. Ты выключаешь свои сущности. Единственный способ это сделать по ЕЦСному, по хардкорному, это удалить компонент. Так как у тебя ЕЦС с архетипами конечно же, то это активирует копирование памяти всех компонентов в другой архетип. Потом система пропукивает список твоих сущностей, создает новый список компонентов рендера, сравнивает с предыдущим, находит удаленные компоненты (в bevy так, по крайней мере), и перестраивает свои внутренние структуры данных.
Даже по этому описанию, как ты понимаешь, работы там не мало. Это совершенно точно не будет эффективнее простого сообщения об отключении объекта.
> tangy td
https://store.steampowered.com/app/2245620
Выводит на главную страницу
И такие траблы еще только при одном компоненте, даже не двух и не десятке.
> Ну смотри. Ты выключаешь свои сущности. Единственный способ это сделать по ЕЦСному, по хардкорному, это удалить компонент.
Нахуя, я совсем отбитый что ли так делать? Кто мне мешает в компоненте связанном с рендером флажок поменять на фолс?
В том. что это уже будет не ecs, а ооп, потому что этот флажок где то хранится (и флажочек скорее всего не один), а значит ты шатаешь кэш, а еще ловишь все удовольствие от промахов предсказателя перехода по if
> что это уже будет не ecs, а ооп
Ты реально дебил
> потому что этот флажок где то хранится
Да, в компонентах в ецс хранятся данные
> а значит ты шатаешь кэш, а еще ловишь все удовольствие от промахов предсказателя перехода по if
А это хуже чем структурные изменения?
Проблема фильтрации любых сущностей есть везде в любом случае и есть разные варианты как с ней работать, и юзаешь ли ты ецс или нет тут абсолютно никакой роли не играет.
Если я не прав - напиши как решить эту проблему так, что именно ецс тут мешает а иной подход не мешает. (Если что, я знаю, что никак)
В юнити ецс под капотом это старый добрый SOA, например, чего ты скорее всего не знал.
вроде речь шла не про какой-то идеальный абстрактный ecs, а про конкретный unity.entities, а там есть флажочек и он работает
каждый кадр по 10 тысяч компонентов включать-отключать конечно же не надо
> вроде речь шла не про какой-то идеальный абстрактный ecs
Идеальный абстрактный ецс допускает любые данные в компонентах, так что он вдвойне шиз.
А также допускает, что у тебя не вся игра игра на ецс.
Я хз вообще что за дебилиусы считают, что если ты применяешь для чего-то ецс, то должен обязательно абсолютно всё делать на нём, я даже тут вроде читал какого-то шиза который заявлял, что ецс говно потому что аниматор на нём получится говном а если я делаю его не на ецс то это уже значит что я делаю костыли и так непраивльно, надо делать на ецм. НАХУЯ. ПОЧЕМУ. ДЛЯ ЧЕГО. КТО СКАЗАЛ. КОМУ НАДО. ААААААА
Потомк что единстенный рнпльный плюс ецс был бы кэш локалити, а он убивается любым твоим смешением, и ецс стаеовится нинужнл. Подходит только видосиков про прыгающие 100000 кубикшв.
> Потомк что единстенный рнпльный плюс ецс был бы кэш локалити, а он убивается любым твоим смешением, и ецс стаеовится нинужнл.
А ЧТО НУЖНО ТОГДА
Ну типа лол, напиши тогда как решить проблемы дырок с временно ненужными данными - эта проблема в любом случае есть, у неё нету единственного идеального решения.
В какой то ситуации линейная укладка в памяти с дырами нерелевантных данных будет лучшим варианьом, в какой-то может есть смысл группировать по чанкам в мире, в какой-то может есть смысл иметь отдельный геймплейный домен и графический и систему синхронизации между ними, в каком разделить это ещё на разные миры.
Тут все ситуативно, и помножено ещё на все факторы скорости разработки - вряд ли ты будешь на практики всё это пробовать, если у тебя игра не за сотни миллионов долларов.
>А также допускает, что у тебя не вся игра игра на ецс.
именно так - главная фишка екс - кеш френдли. все. А любой твой пук в рандомное место массива компонент - убивает это.
не надо рассказывать про какое-то там удобство, геймдизайнеров - это все жопа.
удобства нет - в дебаге это полная жопа - потому что у тебя поток каких-нибудь Transform и ты просто не можешь узнать почему конкретно этот Transform двигается вот сюда, а должен был вот туда.
для дизайнера - миллион каких-то кирпичей - хуй знает как из этого говна собрать орка или сундук. Я уж промолчу про момент, когда компоненты начнут дублироваться - потому что какой-то программист не нашел нужное, и сделал копию.
>Ну типа лол, напиши тогда как решить проблемы дырок
именно поэтому реальное екс так и остается чисто академическим и бывает двух видов:
- это ООП с паттерном компонент, которое маркетологи обозвали ecs для повышения продаж
- разраб - шизоид, у которого нет цели сделать продукт - у него цель сделать идеальное ecs
про маркетологов екс... вот например
>>1086016
шизики говорят что без екс бы не сделали.. ложь-пиздешь и обман. Было полно игр с миллионами юнитов. и не в виде кубов, а с реальной анимацией - да теже первые total war. казаки. или игры где можно было устраивать баталии миллионов стикманов (они на юнити конечно - но еще древнем, где никакого реального екс не было, и даже все еще делали миллионы Монобехаверов)
>В годоте конечно есть нода для новичков, удобная для каких то разовых операций, но из скрипта есть удобный доступ прямо к физ.серверу через direct_space_state.
Удобный и срущий пустыми variant словарями даже если не произошло коллизии, вот такая вот удобность. Юнити то 100000 рейкастов покажет, да даже годот их покажет, но с ньюансом - такие цифры может показать вызов рейкаста непосредственно внутри рантайма движка, а не через апи. В 4 ты либо рейкастишь нодой, либо пытаешься оптимизировать через raycastquery, за простой рейкастинг тебе быстро прилетят пропуки, как только количество рейкастов за кадр приблизится к 1000, а цпу вместо полезной работы все больше будет обслуживать аллокации
На 100000 рекастами и не надо пользоваться, там другие алгоритмы уже. Поля векторов, карты высот, отряды с лидерами, боиды, астары по клеточкам в конце концов. Можно сделать простенький свой райкаст по аналогии с вульфенштейновским - там очень простая математика рассчета пересечений с сеткой. Если уж никак без рейкастов, то батчить, кидать луч раз в 1-2 секунды.
ECS уже не столько актуально с точки зрения производительности. у современных процессоров и так больше кеши. любой, даже самый неоптимизированный ООП код, на современном процессоре будет выполняться быстро, если не нужно вычислять миллионы одинаковых операций.
проблема производительности никогда не была в поведении игры, она в ядре движка. для того, чтобы оптимизировать ядро, не нужно заставлять пользователей переделывать все на ECS, нужно просто использовать data oriented дизайн для внутренних стуктур данных. то есть вместо массивов структур нужно использовать структуры массивов, линейность в памяти не имеет значения, тк кеш обновляется случайными страницами памяти, важно только то, чтобы в страницу кеша статистически больше попадало объектов.
>На 100000 рекастами и не надо пользоваться
Очередной проход в "нинужно", никто не сомневался
>Поля векторов, карты высот, отряды с лидерами, боиды, астары по клеточкам в конце концов.
Ну конечно, ведь именно для этого существуют движки, чтобы ты писал сложные алгоритмы для починки уебанства, которое родили на похуй и не запариваясь, и изобретать которые было бы не нужно, если бы кое-кто не сделал из апи движка variant-нетипизированный пиздец.
>Можно сделать простенький свой райкаст по аналогии с вульфенштейновским
А можно просто починить апи (или использовать движок с нормальным апи) и не надо будет изобретать простенький рейкаст, реализовывая дополнительный физический движок для отслеживания столкновений.
>там очень простая математика рассчета пересечений
Если в этой "простой" математике не фигурируют деревья с быстрым поиском - то я сильно сомневаюсь что такое отслеживание коллизий будет дешевле по производительности вызовов direct space со всеми его аллокациями на мусорные variant словари, а если они там представлены - то такую математику простой не назовешь.
Не ну если для тебя octree сложно, то конечно тут нечего обсуждать. Тебе остается только брутфорсить перебором рейкастов.
давай признаем - ты просто ненавидишь ецс в любом виде, чистом или нет, потому что в годоте его нет
как только в годот завезут ецс, пусть в 10 раз более тормозной - сразу станешь его защитником
как раз octree можно сделать на компонентах и вынести его в unity job да ещё оптимизировать burst'ом - вот тебе и пример "невидимых сущностей"
Ну да, мне сложно писать все за автора движка. Я делаю игры, а не октодеревья для реализации того что и так блять встроено в физический движок(те самые деревья), обеспечивая аналогичную производительность кустарному решению, но с маленьким ньюансом в виде того что оно спрятано за ублюдочным, срущим аллокациями апи. При чем годот в этом плане абсолютно уникален, только он догадался превратить апи движка в вариант месиво только ради того чтобы любимая игрушка хуана под названием gds продолжала свой убогий жизненный цикл
Тебе и не нужно писать ничего за автора движка, автор писал движок общего назначения, у тебя уникальная ситуация 1000000 объектов, встроенными физ движками это не симулируется, значит пишется свой облегченный. К чему ты вообще годот приплел- непонятно, у тебя шиза какая то видимо. Кстати, тащи пруфы с профайлерами и отладчиками что аллокации занимают какое то значимое время, иначе пиздабол.
Нет конечно. В годот ради юнитидаунов и C# завезли, и я каждый раз пишу что он не нужен.
> 1000000 объектов
В какой момент вызов рейкаста превратился в обьект? Ну не считая того что апи годота возвращает нетипизированный словарь в качестве результата, но это конечно половые проблемы исключительно годот-апи. Мы вроде как начали с обсуждения безобидной функции рейкаста, которая в нормальных движках создает структуру или линейный массив структур
>К чему ты вообще годот приплел
Ну так годотю ж обсуждали. У тебя контекстное окно переполнилось?
>Кстати, тащи пруфы с профайлерами и отладчиками что аллокации занимают какое то значимое время, иначе пиздабол.
https://sampruden.github.io/posts/godot-is-not-the-new-unity/
Советую ознакомиться, занимательнейший документ
>В какой момент вызов рейкаста превратился в обьект?
У тебя лошадь и телега местами перепуталась. Очевидно, у тебя проблема X Y. Какую задачу ты пытаешься решить для 100000 объектов рейкастом?
Ну так это для юнитидаунов, их проблема. Им говорили не брать C#.
Я вот думал а чего это вдруг аллокация чего то стоит, это же просто увеличение указателя на число. А потом вспомнил что в этом недоязыке же потом все нулями заполняют,даже если потом переменные это перезапишут, ололол
>Какую задачу ты пытаешься решить для 100000 объектов рейкастом
Можно взять классическую буллетхелл проблему, и например и сделать каждой пульке коллизию на рейкастах, это достаточно удобно, а сами пульки рисовать средствами visualserver/renderingserver. Аналогично рейкаст-стрельба моментальными пулями без баллистики. В нормальном движке это делается без проблем упомянутым тобой апи, а в годоте это делается нодой, чтобы скомпенсировать уебищность апи движка в разрезе рейкаста от хуана.
>>1086173
Затем что если бы ты делал игры на годоте, то знал бы что gdnative/gdextension - это единое апи для всех языков. Да, для с++, для rust, для c# и для gds - будут одни и те же проблемы с тоннами мусорных аллокаций
Ну так я ж тебе сказал, принеси пруфы из дебаггера/профайлера что аллокации для c++/rust занимают существенное время.
>Можно взять классическую буллетхелл проблему
Можно. Но вот незадача, в буллетхеллах 100 пулек, а не миллион.
>и например и сделать каждой пульке коллизию на рейкастах, это достаточно удобно,
Зачем, если это делается элементарно через радиусы и distance_squared
>Аналогично рейкаст-стрельба моментальными пулями без баллистики.
Классно, но причем тут миллион? А если у тебя 100 выстрелов в кадр то ты хоть нодой можешь делать.
> в годоте это делается нодой, чтобы скомпенсировать уебищность апи движка
Но ты же шизофреник, потому что только что писал про апи raycastquery ))))
>>1086178
ты уводишь тему в сторону пытаясь найти в годоте хоть какие-то плюсы чтобы оправдать его перед юнити. нехорошо. займись чем-то одним
Я принес тебе пруфы. То что там используется с# - не имеет значения, потому что управляет аллоцированными variant массивами апи движка, а с# маршаллинг задействуется только в момент извлечения из variant словаря значения хита(чего в тесте нет). Если тебе мало - ну окей, чем больше пропукивающего говна на годоте будет, тем может быстрее дадут пизды хуану чтобы тот апи переделал
а кто тебе сказал что технология должна обязательно работать на пределе возможностей, иначе она "нинужна"? ецс отлично работает и с сотней объектов
но даже если взять среднюю 3d-сцену, там будут не сотни, а тысячи сущностей.
годот же на тысяче нодов уже начинает пропукивать и приходится придумывать всякие ухищрения типа использования рендерсервера, C++ библиотек и т. д.
у нормальной же технологии всегда есть оверхед
>Ну так это для юнитидаунов, их проблема. Им говорили не брать C#.
щас бы говорить про шарп, на фоне питонокалла, который вообще-то по своей философии самый медленный язык (вот нах вообще питон брали для скриптов? взяли бы какой-нибудь JS)
>Можно. Но вот незадача, в буллетхеллах 100 пулек, а не миллион.
Ржомба
>Зачем, если это делается элементарно через радиусы и distance_squared
И сколько твои радиусы будут считаться с O(n²) сложностью, шиз?
>Классно, но причем тут миллион? А если у тебя 100 выстрелов в кадр то ты хоть нодой можешь делать
Почему именно 100? 100 выстрелов это перестрелка из 3 мобов, а на 20 мобах у меня игра будет превращаться в слайдшоу? Охуенно придумал бро
>Но ты же шизофреник, потому что только что писал про апи raycastquery ))))
Квери по итогу выйдет немного дороже нод при сопоставимой сложности организации пропускания всех игровых рейкастов через 1 квери, потому это конечно в некоторой степени компенсирующий выход, но я предпочел сделать на нодах в виду наибольшей оптимизированоости
>Ржомба
тебе не нужно считать каждую пулю. тебе нужно считать направление пуль - иначе это не булетхел а хуита. Все пули в булетхелах летят по определенным игровым правилам чтобы игрок мог на них реагировать.
Так что на экране у тебя может быть тыща пуль, а в логике ты просто сложил два вектора, плюс добавил в вершинных шейдерах разброс
>ты уводишь тему в сторону
>движкосрач тред
Поссал в ротеш юнитидебикам.
шитпостинг здесь не одобряется
пиши аргументированные посты или не пиши вообще
> - это ООП с паттерном компонент, которое маркетологи обозвали ecs для повышения продаж
Какое реальное екс? Что это значит?
У нас есть ентити, компонентя, системы - екс, как это не является екс? Напиши почему это не попадает под реальное определение ецс, какое реальное определение ецс и где с ним можно ознакомиться.
>>1086150
> ECS уже не столько актуально с точки зрения производительности. у современных процессоров и так больше кеши. любой, даже самый неоптимизированный ООП код, на современном процессоре будет выполняться быстро, если не нужно вычислять миллионы одинаковых операций.
Практика с тобой не согласна.
> проблема производительности никогда не была в поведении игры
> она в ядре движка.
Каким образом? У нас запущен рантайм движка и жрет 0.1мс в кадр.
Ты пишешь код, какой напишешь, столько выполняться и будет. Прчм вот натурально скомпилируется и будет слаться на проц, движок тут роли не играеи.
Из движкового ты можешь что-то использовать, а что-то не использовать. Что будет считаться ядром тогда? Если я физику движка не юзаю она ядром считается или не считается, является ли она проблемой? А если я из движка юзаю только рендер? Причем делаю это прямыми командами на отрисовку? Что будет тут ядром которое мне мешает?
> для того, чтобы оптимизировать ядро, не нужно заставлять пользователей переделывать все на ECS
Кто кого что заставляет делать? Есть конкретный инструментарий, ты если хочешь можешь его использовать, а если не хочешь можешь не использовать.
Всё что у тебя по факту выполняется в игре - занимает процессорное время, тебе самому исходя из этого решать что и как оптимизировать.
Если ты попробуешь поделать игру и запустишь профайлер, то ты довольно хорошо поймешь что происходит и сколько твой код занимает времени, и какие то выводы это позволит сделать, ты можешь что-то попробовать, поэксперементировать, и сделать окончательные выводы, например, что никакое абстрактное неведомое ядро говно в штаны не подкидывает
> то есть вместо массивов структур нужно использовать структуры массивов
Ты такой умный, наверное никто не догадался и это делается не 1 промптом. Это всё, другие оптимизации не нужны?
А как конкретно соа в какой то движковой системе мне поможет при юз кейсе что я описал?(из движка юзаем только прямые команды на отрисовку через минимальное апи)
>а кто тебе сказал что технология должна обязательно работать на пределе возможностей, иначе она "нинужна"?
Мне это сказал Кодзима на GDC 2014
>ецс отлично работает и с сотней объектов
Работает, но вот ецс-сектанты то носятся с ней как с серебряной пулей.
>но даже если взять среднюю 3d-сцену, там будут не сотни, а тысячи сущностей.
Да не, не будет, там обычно просто один меш склееный.
>годот же на тысяче нодов уже начинает пропукивать и приходится придумывать всякие ухищрения типа использования рендерсервера, C++ библиотек и т. д.
Ну то есть нормальное использование подходящих инструментов - это "ухищрения".
У тебя рот залит мочой, ничего не разобрать что ты там булькаешь.
никаких ецс-сектантов нет, ты просто ущемился от того, что в юнити есть ецс, а в годоте его нет. я ецс вообще не использую, просто в курсе что он имеется
годот это не подходящий инструмент для чего-то более чем "аниме-девка бегает по склеенному мешу"
>тебе не нужно считать каждую пулю. тебе нужно считать направление пуль - иначе это не булетхел а хуита.
Игрок перемещается - держу в курсе. Он может переместиться вовнутрь потока снарядов. Делать снаряды линиями, без возможности создавать сложные визуальные структуры - можно но неинтересно. К тому же ыя делаю шутан от первого лица, где генератор буллеттов не статичен и сам перемещается по сцене непосредственно в процессе генерации пуль, что смазывает поток и не дает возможности как-либо сгруппировать пули в единое коллайд-пространство. Используя ноды-рейкасты - я могу такое сделать с терпимой нагрузкой на цпу даже в браузере.
> >А также допускает, что у тебя не вся игра игра на ецс.
> именно так - главная фишка екс - кеш френдли. все. А любой твой пук в рандомное место массива компонент - убивает это.
Как это соотносится с тем на что ты отвечаешь?
Я делаю мету на ооп, ии и аниматор своим шаманством в рамках функционального программирования.
А вот геймплей на ецс. Причем тут пук в рандомное место?
> главная фишка екс - кеш френдли
А чем тебе просто СОА не угодил без ецса поверх? Это тоже кэш френдли и без всяких ецсов поверх.
Подсказка - ецс это архитектурный паттерн.
> не надо рассказывать про какое-то там удобство, геймдизайнеров - это все жопа.
> для дизайнера - миллион каких-то кирпичей - хуй знает как из этого говна собрать орка или сундук.
Каким оьразом инструментарий для геймдизайнера и ецс связаны? Ты можешь геймдизайнеру что хочешь выдать. Можешь и напрямую ецсные компоненты - разницы по сравнению с обычными компонентами никакой.
> удобства нет - в дебаге это полная жопа - потому что у тебя поток каких-нибудь Transform и ты просто не можешь узнать почему конкретно этот Transform двигается вот сюда, а должен был вот туда.
Как жаль что никто об этой проблеме не думал и не догадался сделать нормальный дебаг(в юнити ецс есть ентити журналинг и инспекторы где все находится и позволяет быстрее найти причину, на проектах с другими ецс часто есть самописные тулзы)
>Ржомба
Открой популярные тайтлы и проверь.
>Зачем, если это делается элементарно через радиусы и distance_squared
>И сколько твои радиусы будут считаться с O(n²) сложностью, шиз?
Ты ебнутый? Ты пульку с пулькой коллайдишь в буллет хелле? Или таки с одним игроком?
>Почему именно 100? 100 выстрелов это перестрелка из 3 мобов
У тебя моб стреляет 30 выстрелов В КАДР? Ты ебнутый? Это даже визуально не отобразить чтобы игрок мог это воспринять. Даже если взять какой нибудь 6стврольный вулкан который делает brr brr, там логичнее целую очередь одним спрайтом и одним конусом обсчитать. Но даже там скорострельность 6000RPM, т.е. 100 выстрелов в секунду, то есть примерно ЕДИНИЦЫ выстрелов в кадр, карл! А обычные автоматы, пулеметы раз в 10 медленнее.
смотри до чего ты опустился в попытках защитить какого-то рыжего аргентинского мужика который про тебя даже не слышал
репорт за шитпостинг
Никто не будет удалять посты, которые тебе не понравились
Чел, расстояние двух полурадиусов на линии это школьная арифметика, ну, 7 класса.
это твоё личное безыгорное мнение
инструмент есть и им пользуются, и у него есть минусы - но не те, о которых ты говоришь. потому что ты не имеешь представления о том, о чём пишешь. так что лучше не пиши вообще
польза зависит от пользователя
у хорошего хозяина всё в дело идёт, а у плохого - в доме бардак
вот вот. а ты не осилил сделать витрину на годоте. ты - плохой хохяин
>Ты ебнутый? Ты пульку с пулькой коллайдишь в буллет хелле? Или таки с одним игроком?
Пулька коллайдится с
1. Окружением
2. Интерактивными обьектами которые держит игрок
3. С игроком
Достаточно первого пункта чтобы понять где эта тема не выгорит любому кто хоть немного понимает в геймдеве. В системах частиц применяют кастомные гпу-солверы коллизий с специально подготовленной геометрией на сцене, а на цпу применяют функционал физдвижка, который даст наилучшую производительность (если не будет обосран хуевым апи, как в годоте)
>Открой популярные тайтлы и проверь.
Какие-то ноунеймы. Фури нет, шутерного соулслайка с плазменным оружем (забыл как называется) тоже нет.
>У тебя моб стреляет 30 выстрелов В КАДР?
Суммарно моб может сгенерировать до 30 буллетов за 2 секунды, выйдя на максимум в 70 +- с учетом того что буллеты продолжают жить в физическом мире пока куда-либо не попадут или не исчезнут по лайфтайму. В процессе их лайфтайма нужно у всех проверять коллизии, потому что обьекты двигаются и могут зайти в поток буллетов. Если выстрелов много, стрелок двигается а снаряды достаточно медленные - группировать их невозможно.
я не пользуюсь годотом. я хозяин в этом треде и мои инструменты - это остроумные метафоры, а не код и не технологии
Безигорный, ты сначала узнай что такое алгоритмическая сложность чтобы не позориться со своими радиусами
Если бы ты знал, что такое алгоритмическая сложность, ты бы сразу понял почему ecs дрисня никогда не взлетит.
Ты всех забанил в годотреде, и теперь сюда пришел всех банить?
я не модератор, я не могу никого банить и в годотреде не сижу
меня самого там банили давным-давно
однако я туда заходил недавно и имел возможность оценить поделия местных анонов и меня это не впечатлило
Ой, сорян, зря быканул >>1086209 , все же еще хуже, ты так и не понял почему создание потока буллетов невозможно, ведь ты не понимаешь концепции движения генератора частиц в мировых координатах
Сорян, но я в отличии тебя знаю что такое аналитическая геометрия, конус, сектор. А ты конечно продолжай брутфорсить рейкасты и греть атмосферу.
Если юнитидауненка назвали юнитидауненком, это может быть не токсичность, а просто наблюдение, правда, факт.
Ну ты уж вспомни как называется, посчитаем на скриншотах сколько там пуль в кадре, 100 или 1000000
Обновление трансформов и быстрота ECS вещи не совместимые, поскольку трансформы иерархические.
Какая разница кого ты как называешь. Проблема в том, что годоти отпетушили друг друга в своем треде, а теперь пришли сюда и опять раскидываются банами. В чем причина этого феномена?
это не было бы проблемой, если бы трансформации хранились в структуре массивов, потому что даже прыжки по иерархии подтягивали бы большинство данных в кеш.
https://youtu.be/aMvVflfLI8E
На 4:49 отмотай
Это явно делалось средствами гпу, но в моем случае - и цпу невеста
Берешь 100 лифтов, а в каждом по 20 кнопок и обезъянка их нажимает. Ну вот и теперь смотришь что будет с трансформами кнопок, если каждый лифт едет со своей скоростью в свою сторону.
вот я изобразил разницу между локальностью и линейностью компонентов (так реализованы архетипы во всех ECS). линейность избыточна, не дает никаких преимуществ и сильно усложняет архитектуру.
для локальности компонентов не нужно даже ECS, потому что она может быть скрыта в ядре движка и предоставлять обычный ООП интерфейс.
Ну тут пара сотен всего, никакими миллионами не пахнет даже близко. CPU у него вроде не слабый, ну видяха старенькая правда но тоже норм.
На 22 минуте есть еще один партикловый колизионный серун. И ты учитывай что у игрока тоже есть партиклы с коллизиями. Плюс в боссы не попали мобы, которые тоже нормально так высираются партиклами, я просто уже не найду нужный футаж, но по памяти припоминаю что срут они нормально. Бюджет в 2к активных партиклов проверяющих коллизию на сцене должен быть заложен. У меня в игре максимум партиклов около трех сотен, но у меня есть дополнительная рейкаст нагрузка (спрей аима, который наводит партиклы только когда враг видим, рикошеты партиклов от стенок), в нативном клиенте партиклам можно даже активировать освещение, три сотни омнилайтов годот тянет хоть и с каким-то умопомрачительным количеством dc
нельзя обсуждать свои проблемы, потому что если недостаточно восторженно написать про годот, вахтёр отрепортит за "движкосрач". он вообще там круглосуточно сидит и репортит все посты кроме своих
поэтому вместо обсуждения движка годоти пишут пространные простыни об использовании синглтонов в мультиплеере или как устроен ецс и могут делать это месяцами
Ну нравится мне омнилайт, нихуя с собой поделать не могу. Можно конечно блум отрисовать, но мне омнилайт нравится больше. Было бы заебись, если бы наконец появился отложенный рендеринг, но а пока имеем что имеем.
> локальностью и линейностью
Выдуманные тоьой термины.
Вернее локальность и линейность есть, но они не значат то что ты говоришь и даже пересекаются в олном месте, потому что линейность гарантирует локальность.
> линейность избыточна, не дает никаких преимуществ и сильно усложняет архитектуру.
Ага, целый один индекс вместо плавающего количества разных(что в теории решается кодогеном, конечно, но все же это лишнее усложнение) заставляет хранить
промахнулся постом
кто тебя довёл до жизни такой? неужели годот
Да я шучу, я же не стукачок как ты , отправлять не стал. Но по факту же ты нарушил правила двача.
в моём посте не было ничего про это - выдаешь желаемое за действительное
было про сумасшедшего вахтёра - вредного деда-красноглазика
почему-то сторонники опенсорса зачастую такие токсичные шизы, которые сами себе палки в колёса вставляют. а потом удаляют целые репозитории или собственные игры со стима когда в голову внезапно ударит
Если ты там так же токсил, ничего удивительного, что тебя забанили.
нет, я не токсил и я не фанат опенсорса
идея звучит привлекательно, но на деле имеем то, что имеем
поэтому весь стоящий код - закрытый и охраняется семью печатями. за редкими исключениями
Верь в это. Вся такая вера основывается на незнании, какое же там гумно в этом закрытом коде.
Кто видел закрытые колбасные заводы, колбасу больше не ест
я видел этот код своими глазами
напряги зрение - и увидишь голограммы
>плавающего количества разных
компилятор выражения обращения к массиву вида foo[bar] трансформирует в одну инструкцию, у которой эффективность такая же, как у обычного указателя.
кстати, до популяризации unity ecs, все ecs движки имели первую архитектуру. это именно unity популяризовал архетипы.
> компилятор выражения обращения к массиву вида foo[bar] трансформирует в одну инструкцию
Причём тут инструкция, где я говорил про количество инструкций?
Я говорю, что система более сложная когда у тебя разные индексы и требуется эти индексы хранить и менеджить, и доверху еще и обертку как то генерировать чтобы ты из кода мог это дергать нормально.
> кстати, до популяризации unity ecs, все ecs движки имели первую архитектуру.
Спарс сет: ну да, пошел я нахуй
так как индексы компонентов не меняются, в отличие от архетипов, можно в системах "регистрировать" нужные компоненты один раз. например, в системе движка отвечающую за рисовку можно сделать список struct EntityId { int transform_id, renderer_id } и заполнять один раз при изменении компонентов (в событии каком-нибудь).
Реально прикольный рантайм пихла, без шуток. Но лицензия конечно мемная
У первого семантика динамического изменения дерева, у второго - добавления неоднородных элементов в коллекцию. То есть элементов, которые ничего не знают о контейнере, в которых их добавляют, но узлы знают что их добавляют к родителю, и у них есть свойство parent, поэтому семантика неоднородной коллекции в данном случае является неправильным дизайном.
SetParent в одном методе заключает все операции с деревом. add_child/remove_child искусственно их разделяет на 2 этапа (что еще медленнее), и получается что-то вида this.node.parent.remove_child(this);
Это еще усложняет реализацию add_child/remove_child, потому что нужно больше проверок и т.д.
А как в Unity отделить объект от дерева сцены? Это вообще возможно? Я нашёл только один метод "DetachChildren()", но, кажется, он помещает всех детей под root, т.е. не выгоняет их из дерева.
>искусственно их разделяет на 2 этапа
В Godot 4 добавили метод Node.reparent(new_parent: Node), которая сразу перемещает ноду (на которой этот метод вызывается) к указанному в аргументах родителю. Можешь воспринимать её как прямой аналог SetParent(), если хочешь... Исходников Unity у тебя всё равно нет, чтобы сравнить реализации.
Метод Node.remove_child() нужен для того, чтобы остановить обработку ноды в рамках дерева сцены. То есть нода вне дерева сцены не отображается, не влияет на физику, не принимает ввод с клавиатуры и т.д., но продолжает существовать в RAM и может отвечать на пользовательские запросы и пользовательские обработчики событий. Я даже не представляю, как реализовать что-то подобное в рамках API Unity...
По идее, Godot может иметь несколько деревьев сцены одновременно, но можно ли (и насколько сложно) сделать это на практике - не знаю, не пробовал. Т.к. у любой ноды есть метод get_tree(), возвращающий значение только пока нода в дереве, и, значит, ноды могли бы иметь разные деревья сцен в одном рантайме. Хотя, для по-настоящему независимых деревьев сцен нужно как-то избавиться от всех движковых синглтонов...
>this.node.parent.remove_child(this);
Что это? Код Unity? Если тебя волнует
>(что еще медленнее),
То нужно смотреть в исходники Godot на GitHub, а не гадать по API Unity. Там они много чего меняли за последние годы, оптимизируя (ускоряя) взаимодействие с деревом сцены.
Я подозреваю, что "дерево сцены" в Godot и Unity вообще имеет разное значение. Как я понимаю, в Unity "дерево" касается только transform, а всё остальное от него никак не зависит. В Godot же, напротив, от "дерева" зависит вообще всё, за редким исключением (когда ты ставишь галочку top_level, например, или используешь CanvasLayer, и т.п.). Можно сказать, что дерево Unity - слабое, а дерево Godot - сильное. Тем более что в Godot нет понятия "компонента" - ближайший аналог "компонента" - это дочерние ноды в дереве. И ограничение "1 нода = 1 скрипт" - это тоже следствие сильного дерева...
Алсо,
>элементов в коллекцию
Дерево сцен в Godot под капотом разделяется на несколько независимых списков, которые обходятся движком в более эффективном режиме, чем если бы он постоянно бегал по дереву. То есть, например, физические ноды в дереве - это не то же самое, что реальные физические сущности в физическом движке. Аналогично с графикой, скриптами и т.д. Всё под капотом оптимизировано и "дерево сцен" - это только абстракция над внутренностями движка для удобства пользователя, а не реальная структура работы движка.
Но я, если честно, не сильно копался в исходниках, только поверхностно глядел когда-то.
> А как в Unity отделить объект от дерева сцены?
SetParent(null)
>SetParent(null)
В документации Unity данная фича никак не описана, а проверить я не могу.
Но ладно, а если нода сделает так сама с собой - кто её возвращать обратно будет-то?
Я забыл написать, что >>1086488
>this.node.parent.remove_child(this)
На GDScript правильная запись выглядит так:
>get_parent().remove_child(self)
То есть "убрать себя из родителя".
Но! Так делать обычно не рекомендуется. То есть ноды обычно должны управляться своими родителями, не трогая методы родителей. Это родитель вызывает сам у себя:
>remove_child(my_node)
А потом продолжает работать с этой нодой по ссылке, остающейся в my_node. Совсем не обязательно добавлять эту ноду под какую-то другую ноду.
Поэтому новый метод будет выглядеть так:
>reparent(new_parent)
Только когда нода сама себя куда-то перемещает, а у её предка будет:
>my_node.reparent(new_parent)
В общем, не вижу в этом никаких проблем. Сама себя нода извлекать из дерева лишний раз не должна, ведь она может "потеряться" из дерева (если ни у кого нет на неё ссылки), но если она планирует сама себя куда-то переставить - ОК, можно использовать этот новый метод. Стандартные ноды не удаляются Godot автоматически, т.е. пока не вызовешь queue_free(), они будут висеть в памяти, даже если никто на них ссылки не имеет...
>>три сотни омнилайтов
>Бляяяяяяяя
Сами по себе омнилайты почти бесплатные сегодня, если не включать тени.
>>1086243
>с каким-то умопомрачительным количеством dc
Выключи тени. Без теней никаких лишних draw call от омнилайтов не будет.
>>1086233
>Это явно делалось средствами гпу
С чего такой вывод? Пару сотен шариков можно и на 20-летнем CPU двигать.
>Это вообще возможно?
Нет. В unity нельзя создать объект/компонент не привязанный к сцене. Это ограничение движка. SetParent(null) меняет родителя на сцену.
>reparent
Это обертка удаления, добавления.
add_child, remove_child не должно быть публичным API. Это плохой дизайн. У узла уже есть родитель, если у тебя есть дочерний узел, то у тебя есть и родитель. Проблема в том, что в remove_child можно передать узел, который не является дочерним, это лишний источник проверок и ошибок. С SetParent это просто невозможно.
Стесняюсь спросить, но уважаемые движкосрачеры вообще в буллет-хеллы играли? Или хотя бы классические сайд-скроллеры с много пыщь-пыщь на экране. Мне просто очень интересно, как движкосрачер с миллионами пулек в секунду представляет себе игрока в свою игру про пульки. Или он не для игроков это делает, а просто чтоб было? Чтоб можно было написать "нашу игру невозможно пройти до конца" в промо материалах? Чтоб игрок отлетал на первой секунде после начала игры?
Я вот, честно, не люблю этот жанр(ы) и никогда всерьёз не играл в них. У меня тупо недостаточно быстрая реакция, и я слишком быстро раздражаюсь из-за своих ошибок. Короче, этот жанр не для меня и делать игру в этом жанре я никогда не буду. И я думаю, что чтобы рассуждать о технических моментах таких игр, нужно быть как минимум хорошим игроком в них, а лучше - быть фанатом жанра. Т.е. только с опытом игры в такие игры приходит понимание, что там должно быть и как. Чужие слова о том, как что-то где-то должно быть, без подтверждения на опыте, ничего не стоят.
Аналогично со всеми остальными gameplay-first жанрами игр. Если вы не умеете играть, не разбираетесь в играх жанра, не любите их как игрок - какой смысл что-то писать о технических нюансах? Вы не сможете сделать хорошую игру в этом жанре, даже если у вас будет бесконечная скорость выполнения кода, бесконечное количество оперативной памяти и бесконечное время на поиск алгоритмов...
>Это обертка удаления, добавления.
Ну да, ты прав, в исходном коде так:
>data.parent->remove_child(this);
>p_parent->add_child(this);
Но это не важно. Потом могут оптимизировать.
>что в remove_child можно передать узел, который...
>>1086516
>если я вызову add_child с узлом, который...
Зачем ты такими вопросами задаёшься вообще?
Накидал тебе схему в пейнте для понимания сути.
>>1086518
>к типу данных "дерева"
"Дерево сцены" - это не тип данных.
Анон, у тебя с головой все норм? Рассказал про свою нелюбовь к жанру, потом ее спроецировал на меня (я тот кто рассказывал в деталях про рейкаст нодой), выдумал себе что-то и сидит довольный. Если что - я буллетхелл привел в качестве всем понятного примера, у меня в игре плазмоган с очень быстрой стрельбой есть как один из видов вооружения, который в виду того, что подразумевает большое число интерактивных проджектайлов, да еще и делается на годоте - требует особого подхода чтобы игра не косплеила хрюкающую собаку, когда таких стреляющих плазмоганов на сцене будет больше 10 штук. Ну а рейкасты это самый дешевый способ проверить коллизию, если нет возможности посчитать коллизию математически (а ее нет в моем случае).
>Зачем ты такими вопросами задаёшься вообще?
Как зачем? Чтобы показать некомпетентность главных разработчиков годота.
Зачем нужно удалять часть дерева, и иметь все связанные с этим проблемы? Что это даст? В unity просто выключаешь флажок активности объекта и все, это то же самое.
>Рассказал про свою нелюбовь к жанру
Я рассказал, что не понимаю этот жанр, потому что не умею/не могу в него играть.
>потом ее спроецировал на меня
Никуда я не проецировал. Просто такое ощущение, что местные срутся об играх, в которые они не играли, не играют и не будут играть. Типа "а вот в симуляторе песка миллионы песчинок - как %движокнейм% это потянет (даже если потянет, делать не буду)?" - в чём смысл такого срача? Напоминает мерянье тупыми бенчмарками, где на реальное качество продукта всем насрать, пока у него больше попугаев на каком-то специально созданном бенчмарке.
>у меня в игре плазмоган с очень быстрой стрельбой
>стреляющих плазмоганов на сцене будет больше 10 штук
Ну вот тут возникает вопрос к тебе: а ты уже пробовал в это играть? Чтобы там было "больше десяти быстро стреляющих плазмоганов"? Или просто нафантазировал и теперь ищешь какое-то супер-оптимальное решение, не сделав даже одного, самого медленного плазмогана?
>рейкасты это самый дешевый способ проверить коллизию
Главная проблема рейкаста в том, что он имеет бесконечно малую толщину. Тебе там нужен как минимум ShapeCast3D со сферой. Но если твои снаряды движутся медленно, то касты могут быть избыточными - они нужны для моментального определения пересечения, а не когда снаряд летит ползёт через пустоту минимум 30 секунд или больше...
>Зачем нужно удалять часть дерева, и иметь все связанные с этим проблемы?
Зачем нужны молотки и гвозди, если можно случайно ударить себя по пальцу?
>Ну вот тут возникает вопрос к тебе: а ты уже пробовал в это играть? Чтобы там было "больше десяти быстро стреляющих плазмоганов"
Скажем так, я не просто пробовал - я залипал в это говно большую часть детства и юности, я понимаю какой геймплей делаю
>Или просто нафантазировал и теперь ищешь какое-то супер-оптимальное решение, не сделав даже одного, самого медленного плазмогана?
Это супер оптимальное решение существует только потому что у годота супер неоптимальный рейкаст через апи. В других движках так ебаться не надо.
>Главная проблема рейкаста в том, что он имеет бесконечно малую толщину
Мне не нужна идеальная точность, снарядики не настолько большие чтобы это имело видимый эффект непопадания, да и шейпкасты достаточно дорогие, без возможности оптимизации относительно длинным лучом для предсказательного столкновения.
>ползёт через пустоту
Еще один. Снаряд не ползет через пустоту, в этой пустоте на пути снаряда в любую секунду может материализоваться обьект, который этот снаряд перехватит, и таких активных обьектов на сцене много.
> В документации Unity данная фича никак не описана, а проверить я не могу.
Пикрил. У тебя не получилось в гугл написать?
> Но ладно, а если нода сделает так сама с собой - кто её возвращать обратно будет-то?
Ну мы тут всё так проиграммисты, поэтому должны понимать, что это не "нода делает сама с собой", а процессор выполняет некий код. Можешь инициировать выполнение этого кода где угодно.
Например ну я не знаю someTransform.SetParent(null), где someTransform это ссылка на нужный нам объект - которыц ты можешь прокинуть через инспектор, или найти на сцене, или при кодов инстансе сразу вытащить из созданного объекта.
То есть в годоте нет флажка деактивации объекта, и чтобы выключить объекты нужны удалять поддерево и где-то его сохранять?
Пока узлы являются частью дерева, их время жизни управляется сценой. А так тебе самому надо подчищать эти узлы. Очередная ошибка архитектуры годота. А все потому, что Хуан - некомпетентный самоучка.
>чтобы выключить объекты нужны удалять поддерево
Всё зависит от того, что ты хочешь "выключить". Есть куча разных способов что-то отключить и обратно включить. Вырезание части дерева просто делает всё сразу, что удобно для прототипирования.
>их время жизни управляется
Ну, в релизной версии ты, конечно, должен всем чётко управлять и не допускать никаких утечек. Но до релиза ты всё равно не доживёшь, а время жизни прототипа не позволяет ему насрать в оперативке слишком сильно. Все потерянные ноды удаляются из памяти после завершения процесса движка.
>>1086541
>Пикрил.
Вот сначала кликни на эту ссылку, прочитай статью, а потом покажи, где там написано, к чему должна привести передача null. Или это такая фишка юнити - догадываться о недокументированном поведении? Которое могут произвольно сломать в следующей версии, ничего не обновив в документации (т.к. там и не было ничего написано до изменений).
>процессор выполняет некий код
Умник, а почему не "электроны толкаются между атомами кремния"?
>Можешь инициировать выполнение этого кода где угодно.
Это признак говнокодера, превращающего код в нечитаемую лапшу.
>>1086538
>неоптимальный рейкаст через апи
Раз ты знаешь, что нужно исправить, почему не исправишь? Исходники открыты и лицензия допускает делать с ними что угодно. Бери и оптимизируй. Потом будешь хвастаться, как ускорил рейкасты в движке в десять тысяч раз и подарил эту оптимизацию всем юзерам движка...
>Раз ты знаешь, что нужно исправить, почему не исправишь?
Потому что это невозможно. Я только иду на ухищрение чтобы значительно смягчить эту проблему, но полностью от нее избавиться невозможно, покуда апи такое смешное.
> Вот сначала кликни на эту ссылку, прочитай статью, а потом покажи, где там написано, к чему должна привести передача null. Или это такая фишка юнити - догадываться о недокументированном поведении? Которое могут произвольно сломать в следующей версии, ничего не обновив в документации (т.к. там и не было ничего написано до изменений).
Всм? Тут абсолютно чётко написано что оно делает - устанавливает родителя. С картинками причем, пикрил.
Если родителем установить никого - значит родителем будет никто. Для дебилов: если родитель никто - например у MainCamera на скрине нет родителя.
> Умник, а почему не "электроны толкаются между атомами кремния"?
Потому что уровень зависит от задачи и скоупа целей. Если мы занимаемся программированием игр на юнити серьёзно, то мы должны понимать что происходит с сишарп кодом в общих чертах, что такое mono и il2cpp, и что попадает на процессор(знание конкретных процессорных инструкций не обязательно).
Если бы у тебя оно было - ты бы не рассуждал сейчас абстрактно о вещах которых не понимаешь в контексте который отношенич к реальности не имеет. Какое нахуй "кто её возвращать обратно будет" - кто придумаешь тот и будет. Охуеть.
> >Можешь инициировать выполнение этого кода где угодно.
> Это признак говнокодера, превращающего код в нечитаемую лапшу.
Гений, тогда абсолютно все это говнокод потому что что угодно попадает под определение "что угодно".
А сколько рейкастов бросаешь?
У меня в 2022 году на Godot 3 без проблем получалось 1200 рейкастов (матрица 40x30) за один тик физики (30 tps) на ядре процессора 2007 года (около 3 ГГц). Использовал только одну RayCast ноду и двойной цикл for на GDScript. Интересно, сколько рейкастов можно сделать на современном ЦПУ в Godot 4?
>что угодно попадает под определение "что угодно"
Гугли "объектно-ориентированное программирование".
>у MainCamera на скрине нет родителя.
По-твоему, SampleScene - это null?
В вебгл где-то 1300 в рамках одного тика 60фпс физики выжал до первых лагов. В нативном клиенте по ощущениям можно высосать раз в 5 побольше, но не проверял. Проц r7 6800h мобильный.
> Гугли "объектно-ориентированное программирование".
Что угодно из ооп попадает под определение что угодно. Харош шизу нести, какой объект тебе надо тот пусть и вызывает код, что за тупые вопросы
> По-твоему, SampleScene - это null?
У тебя в доках написано, что в юнити есть сцены и есть объекты на сценах. Объектов не на сценах нет.
> Раз ты знаешь, что нужно исправить, почему не исправишь? Исходники открыты и лицензия допускает делать с ними что угодно. Бери и оптимизируй. Потом будешь хвастаться, как ускорил рейкасты в движке в десять тысяч раз и подарил эту оптимизацию всем юзерам движка...
Любой действие обуславливается экономикой.
Значит трудозатраты не стоят того, чтобы этим хватсаться и у себя применять - слишком малая награда.
>Объектов не на сценах нет.
есть префабы и scriptable objects
Это префабы и скриптабл обжекст. Тебе что надо? Объект со сцены превратить в префаб или скриптабл обжект?
мне ничего не надо, я зашёл в тред и увидел ложное утверждение
>можно было сделать игру
Можно. Но зачем?
>слишком малая награда
Какая награда нужна в сфере развлечений, где движки делают потому, что это интересно и весело, и игры разрабатывают чисто чтобы пофлексить перед друзьями своими бесполезными творческими навыками?
На всех остальных платформах старый рендер без фич.
Даже и тут наебали.
Ты довольно редкий кейс описываешь, обычно игры делают чтобы народу показать и/или подзаработать.
GLES2 база
годоту надо было оставаться ретро-движком, имитирующим старые игры и развиваться в этом направлении
и не лезть на полянку к старшим пацанам
>На всех остальных платформах старый рендер без фич.
Вщет mobile это тоже forward+, просто это такой форвард который совместим по фичам с gles. За это можешь сказать спасибо говнофонам, которые до сих пор рабочего вулкана не имеют. Гарантированно вулкана нет только в вебе.
mobile и compatibility это одно и то же
https://slicker.me/godot/renderers.html
В статье которую ты скинул мои слова подтверждаются. Мобайл и глес уравнены по фичам, но при этом у вулкана свежее архитектура и он обходит глес по производительности, если есть поддержка этого апи. Все это создано чтобы покрыть побольше устройств (в части которых вулкан хуево или вовсе не реализован и там происходит фоллбэк на глес). Но тебе вообще никто не мешает собрать forward+ билд под любую платформу, просто есть риск что на части мобилок рендер отвалится или будет артефачить из-за того что разрабы конкретного чипа хуево внедрили апи вулкана.
Ну то есть у годота есть одна реальная платформа - ПК. Все остальное нужно "самому компилировать".
Это и значит есть все платформы. Компиляция одной строчкой делается
>На всех остальных платформах старый рендер
Такие жалобы направляй разработчикам GPU.
и только годоти продолжают сидеть на gdscript
годоти тоже хотели c#.
хуан это как злой джин, который выполняет желания таким образом, что становится только хуже.
гейм мейкер вроде бы устроен принципиально иначе чем годот
там нет взаимодействия скрипта с ядром через апи, там gml транспилируется в си и конпелируется в нативный экзешник
ещё есть вариант с выполнением GML в виртуальной машине, я не в курсе как это устроено
что в словочетании "ПОДДЕРЖКА платформы" тебе не понятно? пердолька, которую надо компилировать, это не поддержка.
по факту годот поддерживает одну платформу, остальное это поддержка уровня "у меня все 3 года назад работало, компилируйте и решайте проблемы сами".
это будет не полноценный C#, можно только вызывать методы из C# библиотек из скриптов.
>пердолька, которую надо компилировать
Не надо там нихуя компилировать. Просто берешь и без задней мысли собираешь билд через экспорное меню forward+ на любую платформу с вулканом, включая мобилки. Даже фоллбек на глес будет работать. Впрочем, если ты ссышься компилировать годот - то тебе нужен баринский движок, в котором все уже есть и скомпилировано заранее.
годоти не хотели C#
C# хотели юнитидети которые сбегали на другой движок
ну им и кинули гоавняшку чтоб игрались
нормальные (нормисоблядские) языки не нужны в геймдеве и больше вредны
пример юнити это показывает там урезаный C#
в годоте есть лучший язык (c++)
никакого словосочетания "поддержка платформы" в предыдущих сообщениях не было, ты начал маняврировать
то что ты описал это обычное поведение любого софта
буквально единицы софта в мире гарантируют строго математически какое то поведение через пруверы
любая юнитя точно так же вывалит тебе какой то билд который однажды где то возможно запустился, а сколько в нем еще багов никто не знает. а если ты им напишешь они с большой вероятностью пошлют тебя с пометкой wont fix
показывай официальную позицию хуана, где он утверждает что C# - какашка и что его заставили некие юнити-дети
иначе это выглядит как нелепый копиум фанатичной годособаки, которая не может признать обсёр своего хозяина и поэтому выдумывает оправдания за него
нелепый - потому что ты утверждаешь что какие-то неведомые "юнити-дети" из-под кровати влияют на хуана
в годоте нет с++, а в юнити есть буквально все языки планеты
тупая юнитишавка проецирует про хозяев
в опенсорсе нет хозяев, тут каждый хозяин кода и движка на своем компе
>в годоте нет с++
пей таблетки
у меня несколько игр выпущено на годоте с логикой на c++
ничего у тебя не выпущено, фантазёр
ты круглосуточно ИТТ сидишь простыни катаешь в защиту своего рыжего кумира
типичное врети безыгорника
тем временем я выбираю новую квартирку
юнити могила
как обычно, не вывез дискуссию и перешёл на оскорбления, как истеричная баба
тебя для этого в этот тред и сослали, чтобы тебя унижали
анонимное пустое место, которое само себя не уважает, не способно никого унизить
очень хорошо что ты представился, пустое место
ты сам первый перешел на личности, >>1086663
вот и обтекай теперь
ну тут как раз выступали в защита годот как раз из-за "поддержки" платформ, и что все будет просто работать. а теперь оказывается поддержка это не поддержка.
да всё равно, слабый не слабый
главное что деньги юзера пойдут на гейм мейкер, а не на донаты в годот
ни копейки рыжему скамеру
говняшку кинули microsoft, в виде взятки за добавление C# в годот. так как нужно было отрабатывать говняшку, то C# добавили самым тупым способом, какой легче было реализовать без переделки движка.
годот не нуждается в защите
ты беззубый и напасть не можешь
Хуан написал миллион строк кода и подарил человечеству, в чем скам?
Ни разу не донатил Хуану, но обмениваюсь кодом с другими годотерами, богатеем вместе взаимопомощью
https://www.reddit.com/r/godot/comments/1sz7ike/c_multithreading_experiment/
какая разница сколько там строк, если результат - никакой. разработчики движка и фанаты занимаются агрессивной рекламой, рассказывая что годот это лучший бесплатный движок, хотя это не так. из-за чего другие более достойные движки с более достойными разработчиками не получают поддержку.
да, это обман в каком-то смысле. это типа как корпорация teranos, которая обманывала инвесторов. за такое судят.
ну вот смотри, тут годотя поддерживает скам с имитацией добавления C# который "нинужен" и сделан для обмана "юнитидетей" >>1086683
пример с C# показательный. они поспешили добавить язык для галочки, чтобы потом трубить что у них в движке C#, как в unity. они где то говорят о производительности (вернее, ее отстутсвии), или о нюансах их реализации C#? конечно же нет. что это, если не обман?
честный разработчик не стал бы так поступать, не стал бы добавлять язык таким способом, который делает его непригодным для использования.
они сделали это с одной целью: пустить пыль в глаза, обмануть пользователей.
Результат заебись, есть отличный движок который скачиваешь и делаешь игру через 5 минут.
Это объективно лучший движок по совокупности. Искали всем тредом, никаких более достойных не нашли. Если в каком то движке одна фича лучше, то десять других отстутствуют и так далее.
C# для юнитидетей это просто переходный период чтобы они выучили АРИ на знакомом им языке и потом пользовались этим апи в гдскрипте.
>Если в каком то движке одна фича лучше, то десять других отстутствуют
>десять других
Хуана во всем треде вспоминаешь только ты. Я с ним вообще никогда не общался даже.
причём тут общение? хуан автор годота, вот тебе и причинно-следственная связь
оправдания годоту = оправдания автору
никаких юнитидетей не существует
дети могут учить что угодно, у них голова пустая
а я не могу перейти на годот, потому что у меня накопилась кодовая база на C#, не привязанная к API Юнити
я было обрадовался, когда узнал о введении C# в годоте, но это оказалось скамом, как и всё остальное, что обещал аргентинский мавроди
>я было обрадовался, когда узнал о введении C# в годоте, но это оказалось скамом
Делаю игру на с#, все заебись. но двигло 3.6.2
Зря ты ему это написал, сейчас этот лох неудачник опять начнет ныть что у него одного ничего не получается поэтому все вокруг виноваты.
ты бы не таким самоуверенным, если бы знал какую "игру" он "делает".
Делаю игру моего детства, и игру детства еще пары сотен тысяч школьников моего возраста
>но двигло 3.6.2
а что, там нет типа variant и нет пропуков?
>а что, там нет типа variant и нет пропуков?
Вариант на данный момент смертельно может влиять только при рейкастинге апишкой. Есть еще кое-какое проблемное апи, но я его не юзаю. Формально - апи страшное с точки зрения аллокаций. По факту - если на горячем пути зная проблемное апи - не злоупотреблять им (инпуты с stringname, рейкасты, getnode/add/remove) - пропуков по вариант апи не будет.
Но у godotphysics есть болевая точка - коллайдерную геометрию для активных ригидов нужно собирать из примитивных коллайдеров, если генерировать выпуклыши - при коллизии друг с другом они даютхрюкающую собаку (думаю именно это и было причиной тех ебейших пропуков на видосе). Но конечно можно юзать bullet/jolt и такой проблемы не будет, но мне нужна годотфизика.
>>1086721
Увы, как раз наоборот - юи даже не начинал
>думаю именно это и было причиной тех ебейших пропуков на видосе
Ты угораешь? Там у чела просто видозахват тормозит на некропеке 20 летней давности.
Если ты имеешь в виду годотфизику в 3-ке, то ни в коем случае ее не юзай. Ах да, ты шиз который не слушает советов.
он в коментах отвечал что не тормозит
видеозахваты фильмов на его канале нормально работают
там множество коллайдеров и ригибоди в сцене
Видеозахват фильмову него точно так же тормозит
https://www.youtube.com/watch?v=2WU19oJD5qY
Впрочем от тебя пиздаболки другого и не ожидалось
это годот тормозит, баран
вон топовое видео на канале без годота
Нахуя мне советы безигорных? Кстати советую тебе начать делать игры бтв
интервью с дедулей
> Кстати советую тебе начать делать игры бтв
Мне то зачем советы безыгорника с гта омск. А свои игры я уже все релизнул, мне уже можно и ничего не делать больше.
больно и жалко смотреть на этого деда, на виндоус 98 что-то набивает руками на мёртвом опенгл, кому это нужно в текущем году?
>интервью
Спроси его почему он уязвимости в stb либах отказывается чинить
Ты очень классный
Ты самый лучший кодер движков
Твои идеи самые крутые
>у меня накопилась кодовая база на C#
Если бы ты был настоящим программистом, то ты бы понимал, что переписать "кодовую базу" с одного императивного ЯП на другой императивный ЯП - это настолько просто, что даже тупая программа может справиться (называется транспайлер), то есть даже интеллекта для этого никакого не нужно. А уж в эру искусственного интеллекта твои жалобы на якобы неправильный язык кодовой базы вообще смешны.
Перепиши следующий код
Classobject.gettype().methods.where(x => x.name.contains("zalupa")).foreach(x => x.invoke(Classobject))
На плюсы. Разрешаю использовать любые нейронки.
Ахах
Я бы посмотрел на транспайлер C#2GDS
Оцениваю в 10 человеколет разработки.
Зачем такую шизофрению с рефлексией переписывать? Такому место в мусорке.
Пиши нормально - нормально будет.
Тебя никто не заставлял хуевертить неоптимальный, медленный, раковый код, который еще и оказался неперносимым вендорлокнутым, кек.
В разработке есть принцип использовать разумное подмножество языка, понятно что это в первую очередь выгодно в командной разработке и принцип появился еще во время c++, потому что там то как раз можно много DSL наплодить макросами и все друг друга перестанут понимать
>Тебя никто не заставлял хуевертить неоптимальный, медленный, раковый код, который еще и оказался неперносимым вендорлокнутым
А еще каким-то образом частично оказался в 26 стандарте плюсов. Но ты продолжай свято есть устаревшее неудобное говно применять разумное подмножество функций языка, ведь писать вместо одной строчки пятьдесят - это разумно и переносимо.
у меня действительно примерно так и реализована система взаимодействия с interactable объектами, только сравнения со строкой нет
Очевидное лицемерие, если бы тебя интересовала короткая запись строки ты бы кодил на J или APL каком то
там этот поляк собрал целую кодлу вышедших в тираж старых пердунов
кто-нибудь, расскажите дедам про AI агентов и spec-coding. им пора на свалку истории достойную пенсию
Зумерок какой то
Вот олд лайвкодит
https://www.youtube.com/watch?v=3l4OLh2LtPk
да, это оказалось неоправдано
у меня по задумке было неограниченное количество глаголов для взаимодействия с объектами, но в конце концов всё свелось к банальным "посмотреть", "взять", "открыть" и т. д.
но поздно переписывать, надо идти вперёд, как хуан
>Classobject.gettype().methods.where(x => x.name.contains("zalupa")).foreach(x => x.invoke(Classobject))
Я не разбираюсь в C# и не знаю, что ты называешь "Classobject", но вот код на GDScript:
>for x in object.get_method_list().filter(func(x): return "zalupa" in x.name): object.call(x)
Или можно сделать проще (читабельнее), т.к. мы всё равно не сохраняем массив:
>for x in object.get_method_list(): if "zalupa" in x.name: object.call(x)
На C++ такой код писать глупо, конечно. Попахивает лапшичной архитектурой твоего проекта.
>>1086754
>неоптимальный, медленный, раковый код
А вдруг ему приходится работать с древним легаси? Тут скорость не важна - лишь бы работало...
>оказался неперносимым вендорлокнутым
Нет, создать что-то такое можно на любом языке, даже самом древнем. Но нужно ли?..
>>1086755
>писать вместо одной строчки пятьдесят
А что ты там пытаешься сделать, что тебе нужно вызывать все методы, содержащие одно слово?
Это, кстати, смешной исторический баг, который нашли в одной настолке в 2000-е.
Там добавили способность, которая была сформулирована примерно так же - "если в названии чего-то есть zalupa, то ее мощность удваивается".
По замыслу, это работало на tonkaya zalupa, tolstaya zalupa и т.д.
Вот только, строгое прочтение, матчит все, как: vokzaluparka - теперь у игрока два воказала, linzalupa - теперь удвоенный бинокль
Не используйте матчинг строк без нужды в геймдеве, господа.
У годоти от боли и унижения помутился рассудок. Геймдев не слабых духом.
Кажется, ты тоже прикольный парень, думаю и игры у тебя интересные.
прекращай заигрывать с парнями ИТТ, ты выбрал не тот раздел
Ты как-то извращенно все понял, у меня вообще-то жена есть.
А что не так? Ты же сам хотел, чтобы в ИТТ тебе не грубили.
Чел я в целом на твоей стороне в диалоге выше, но это полный пиздец.
Такой код недопустим в реальной игре и с точки зрения перформанса и с точки зрегия поддержки.
Справдливо возразить - критикуешь- предлагай - а я и предложу - кодогенерацией абсолютно та же задача отлично решается без недостатков.
>не знаю, что ты называешь "Classobject"
Инстанс обьекта некоего ссылочного типа
>но вот код на GDScript:
Анон, я отлично знаю как такие фокусы делаются в нетипизированном говне, где любой ссылочный "обьект" это по сути хэшмап, который можно перебрать. Но речь идет о нормальных языках, производительных, с настоящей типизацией. К которым сверху прикручена рефлексия, которая может сыграть некоторую роль в архитектурных решениях. И в этих языках - данные рефлексии можно кешировать (например на старте один раз выделить рефлексией разные группы методов, сохранить Method ссылки в коллекции, а затем их очень дешево инвокать, мотому что методы - часть типа, а не часть обьекта), в отличии от.
>На C++ писать глупо, конечно.
Поэтому я выбираю с# для скриптов, ведь на с++ писать глупо. Хотя, мейби с вводом в строй 26 стандарта - я еще разок к плюсам присмотрюсь, конечно, всех фич шарпа это не покроет, но некоторую критическую их часть - возможно.
>А что ты там пытаешься сделать, что тебе нужно вызывать все методы, содержащие одно слово?
Это просто пример. В боевых проектах я использовал рефлексию чтобы:
Автоматически генерировать инстансы для типов, которые наследуют определенный тип.
Прописывать данные в статические поля классов (костыль но работал).
Свой deepclone.
Для вызова конфигурируемого файловой конфигурацией поведения обьектов(пикрил) и ресолва методов.
Бесчисленное Object.gettype для любых целей.
Примерно такой список, который невозможно реализовать на плюсах.
>>1086788
У меня нет задач под кодоген, так как я не использую рефлексию на "горячем" пути, либо кеширую ее результаты. Разумеется вот того кода у меня в рабочих решениях нет, но его некоторые части присутствуют.
очень просто. используешь https://github.com/xoofx/CppAst.NET и создаешь source generator на минималках
> У меня нет задач под кодоген, так как я не использую рефлексию на "горячем" пути, либо кеширую ее результаты.
Эквивалент того пиздеца что ты скинул пишется кодогеном.
>Эквивалент того пиздеца что ты скинул пишется кодогеном.
Нахуя он им пишется, а главное зачем? Чтобы что? Ты экономишь один проход генерации кеша и ради этого ебешься с генераторами кода? Мысль конечно интересная, но мне не платят за строчки кода, даже хуже, мне ни за что не платят кроме работающей игры, а написание генератора кода на любой чих только отдаляет меня от релиза и генерирует сложность, которая мне без надобности.
> Нахуя он им пишется, а главное зачем?
Для оптимизации и усложнения регресса(с рефлексией ты свое говно сможешь сбилдить и запустить даже если сломал его, а с кодогеном все компайл тайм)
>Для оптимизации
Видимо оптимизации доступного мне времени на разработку, потому что перфоманс импакт мизерный по меркам поставленной задачи.
>усложнения регресса
Тесты писать заратустра не позволяет? И как меня спасет компилируемая природа генератора от ошибок генерации, когда генерируется не всё? А если нужно покрывать тестами в обеих случаях - зачем мне, как инди разрабу с крайне ограниченными ресурсами - платить больше?
> Видимо оптимизации доступного мне времени на разработку, потому что перфоманс импакт мизерный по меркам поставленной задачи.
А ты проверял?
> Тесты писать заратустра не позволяет?
>>1086815
> но мне не платят за строчки кода
Nani!?
>Но речь идет о нормальных языках, производительных, с настоящей типизацией. К которым сверху прикручена рефлексия
Твой высер с поиском по тсроке не имеет отношения ни к типизации, ни к производительности.
>А ты проверял?
Что проверял? Что написать генератор это неоправданный гемор, высеры которого потом придется дружить с абстракциями кодовой базы? Конечно проверял. А если речь про закэшированные данные - единственный импакт это ресолв данных кэша по ключу, который можно дополнительно скомпенсировать используя frozen коллекции, потому что инвок methodinfo запакованный в делегат (через createdelegate) практически аналогичен прямому вызову.
> Что написать генератор это неоправданный гемор
Я не понимаю и не умею = гемор? Так мб научиться можно.
> высеры которого потом придется дружить с абстракциями кодовой базы
Чел у тебя буквально вызов метода по названию какие нах абстракции, это даже банальным интерфейсом решается.
Да, вот жаль его, вроде бы достаточно умный, еще немного бы подучился нормальным практикам - и делал прекрасные игры, а так, закапывает себя в багодром.
>Я не понимаю и не умею?
Сам придумал сам разьебал. Да хочешь - пиши, я понял что ты сторонник вместо использования готовых инструментов - страдать хуйней ради непонятно чего. Мне такое не надо, я не для того использую лучший язык на планете чтобы вьебывать свое время на хуйню.
>Чел у тебя буквально вызов метода по названию какие нах абстракции
>это даже банальным интерфейсом решается.
Интерфейс не абстракция? Как минимум обмазывать интерфейсами класс придется ручками, и методы вкидывать в интерфейсы тоже ручками. Добавить новый метод = добавь интерфейс с методом, накинь. Все ради того чтобы... ай блять, ведь мы же все равно будем резолвить нужный интерфейс через пару ключ-значение (строка -> интерфейс), надо же, мы сэкономили целое нихуя. Ну, еще получили немного компайлтайма, который опять таки гарантирует целое нихуя, если нет уверенности в корректности работы генератора.
> я понял что ты сторонник вместо использования готовых инструментов - страдать хуйней
Как именно ты это понял? Я тебе говорю почему конкретная практика программирования говно.
Готовые инструменты я использую по полной, если тебе интересно.
> чтобы вьебывать свое время на хуйню.
Так ты его въёбываешь на поддержку говнокода.
> Интерфейс не абстракция? Как минимум обмазывать интерфейсами класс придется ручками, и методы вкидывать в интерфейсы тоже ручками. Добавить новый метод = добавь интерфейс с методом, накинь.
Да что ты черт побери такое несёшь.
Нахуя писать вот это
> Classobject.gettype().methods.where(x => x.name.contains("zalupa")).foreach(x => x.invoke(Classobject))
Если можно
classObject.Zalupa()?
Если там несколько методов нужно у которых в названии zalupa, то почему бы не
GetDolbloebskoeGovno<IZalupa>().zalupa(classObject)
?
При этом мы можем сделать место где будем регать разные имлементации IZalupa с методом zalupa принимающем наш тип, и соответственно все они будут вызываться по строчке выше.
И уже это будет более менее нормальный код с которым можно сделать игру, а не прототип про кубы.
Нахуя ты вообще берешь шарп со строгой типизацией еслт она тебе наэ не нужна? Бери жс тогда.
А, так ты другой анон, вообще отрицающий рефлексию. Я тебе уже все написал про 26 стандарт плюсов все написал. Тебе я тоже не запрещаю хуйней страдать, дрочи свои интерфейсы пока я написал 30 строчек с кешированием и пошел дальше.
Почему отрицающий? Рефлексия норм тема, но её надо юзать там где надо. Твой пример юза - какой то кал.
> Я тебе уже все написал про 26 стандарт плюсов все написал.
Не мне.
>Твой пример юза - какой то кал.
Сообщает мне это человек, который исполняет это
>Если там несколько методов нужно у которых в названии zalupa, то почему бы не
GetDolbloebskoeGovno<IZalupa>().zalupa(classObject)
?
>При этом мы можем сделать место где будем регать разные имлементации IZalupa с методом zalupa принимающем наш тип, и соответственно все они будут вызываться по строчке выше.
Мой пример использования рефлексии описан здесь
>>1086797
То что я изобразил с поиском по вхождению строки в имя метода - просто пример, прикол, рофл, чтобы показать терпильность плюсовиков. Разумеется, таких подходов я не применяю.
> Автоматически генерировать инстансы для типов, которые наследуют определенный тип.
Если активатор креейтинстанс то ок в каких то инфраструктурных штуках.
> Прописывать данные в статические поля классов (костыль но работал).
Нахуя статические поля в классах? Нахуя туда прописывать рефлексией что то?
> Свой deepclone.
Зачем для этого рефлексия, чтобы это супер доррго было? Что ты там вообще клонируешь клонировщикс?
> Для вызова конфигурируемого файловой конфигурацией поведения обьектов(пикрил) и ресолва методов.
Где тут нужна рефлексия? Прост какая то структура данных сериализована, которые ты видимо десериализуешь рефлексией. Но рефлексия для этого не нужна.
> Бесчисленное Object.gettype для любых целей.
Звучит супер сомнительно, я как тоже любитель упороться в метапрограммирование не юзаю почти никогда.
>>1086839
> То что я изобразил с поиском по вхождению строки в имя метода - просто пример, прикол, рофл
Так а чё ты тогда споришь? Я говорю - это пиздец. Ты в ответ какую то шизу несешь вместо того чтобы сказать - это рофл просто демонстрационный пример.
Рефлексия это шизофрения, типа ты забыл какие типа у тебя в программе и что они умеют и пытаешься нащупать вслепую.
Выдумали ее в кровавом интерпрайзе, какие то гении выдумали хуиту что один банк в другой присылает SOAP прям с неведомым кодом, и надо угадать что тот код вообще умеет. Короче совершенно ненужна в полностью контролируемом окружении в геймдеве.
>То что я изобразил с поиском по вхождению строки в имя метода - просто пример, прикол, рофл, чтобы показать терпильность плюсовиков
Поэтому то тебе сразу и сказали что это надо выкинуть и переписать, а ты начал истерить про НИНУЖНО, так что молодец, ты наглядно опроверг терпильность плюсовиков.
>Зачем для этого рефлексия, чтобы это супер доррго было?
Ну скажем так - бывает надо. Клонировщик на базе рефлексии просто самый простой в исполнении и позволяет делать кое-какую магию.
>Нахуя статические поля в классах? Нахуя туда прописывать рефлексией что то?
Чтобы например вшивать значения из атрибутов в статику конкретного класса. Типа, чтобы не опрашивать атрибуты типа в рантайме, а получить их сразу по статическому полю. Тоже надо.
>Где тут нужна рефлексия? Прост какая то структура данных сериализована, которые ты видимо десериализуешь рефлексией.
Проявил бы больше уважения к собеседнику. Я например твои высеры от и до читаю. И ты, если бы немного дольше удержал зрение на картинке, то заметил бы, зачем там может понадобиться рефлексия, в частности вызов методов по их имени и сопоставление типов с их строковыми представлениями. Вообще конечно пиздец, с кем я говорю, ты же даже yaml формат не видел никогда, иначе бы шизобред про десериализацию рефлексией не писал бы.
>Так а чё ты тогда споришь? Я говорю - это пиздец. Ты в ответ какую то шизу несешь вместо того чтобы сказать - это рофл просто демонстрационный пример.
Я это сразу сказал, еще в том посте, который кинул выше. Просто я думал претензии к моим рабочим применениям.
Купи себе подписку на дипсик, у него и то контекст больше и умишка побольше, пусть думает что постить за тебя
У тебя типичный Даннинг-Крюгер. Уныло это все, конечно, лет через 10 наверное до тебя начнет доходить, хотя скорее всего и тогда не дойдет.
>лет через 10
Брух, уже лет через 5 я скорее всего даже иде открывать не буду, будет какой-нибудь AIDE, где я тупо через бота пишу спеки и оно мне рожает фичи, и раз в пару дней запускаю autorefactor чтобы зачистить техдолг. А может, буду вообще безработным бомжом, который будет просить милостыню под дроидпарком
а может через 5 лет ты будешь писать на ассемблере, чтобы сэкономить 32 КБ памяти
технологии не всегда идут вперёд, прогресса не существует
>типа ты забыл какие типа у тебя в программе и что они умеют
да забыл
хорошо, что есть рефлексия
> Чтобы например вшивать значения из атрибутов в статику конкретного класса. Типа, чтобы не опрашивать атрибуты типа в рантайме, а получить их сразу по статическому полю. Тоже надо.
Статика это минус вайб плюс ограничения. Статики в коде быть практически не должно, только в медиаторах с движковой или сдкшной частью где она уже есть либо иначе никак. А также в инфраструктурных штуках, которые иначе не сделать. У тебя получается класс сразу подвзяан на какие то данные и нету 2 инстансов с разными данными. Куда ж это годится?
> Проявил бы больше уважения к собеседнику. Я например твои высеры от и до читаю.
Я полностью прочитал все что ты мне написал и все на что сослался.
> И ты, если бы немного дольше удержал зрение на картинке, то заметил бы, зачем там может понадобиться рефлексия, в частности вызов методов по их имени и сопоставление типов с их строковыми представлениями.
Вопрос всё тот же - почему рефлексия здесь необходима? Это точно не решается без рефлексии?
И всё также - нахуя брать строго типизированный сишарп и максимально отпиливать от него типизацию? Вызов метода по имени из конфижного текстового файла это пиздос и источник поломок на многие месяцы вперед. Причём неявных поломок, которые ты ещё хуй найдешь.
> Вообще конечно пиздец, с кем я говорю, ты же даже yaml формат не видел никогда, иначе бы шизобред про десериализацию рефлексией не писал бы.
В юнити префабы и сцены не yaml? Как считаешь, то что с ними творится можно назвать сериализацией и десериализацией? Я считаю да, это она и есть в самом чистом виде.
> ты
Кстати я выше хоть раз написал "ты"? По моему я комментировал только твои высказывания.
> Я это сразу сказал, еще в том посте, который кинул выше. Просто я думал претензии к моим рабочим применениям.
Значит я неправильно тебя понял, потому что ты писал что его части присутствуют.
К твоим рабочим применениям вопросы тоже появились, потому что примеры что я увидел это не то что "ну хз может ок" а чето совсем куда-то не туда, как мне кажется. Слишком легко ломаемое, слишком плохой перформанс, ну если у тебя .net core вместо юнити то там рефлексия подешевле и признаю хз насколько.
> Брух, уже лет через 5 я скорее всего даже иде открывать не буду, будет какой-нибудь AIDE
Я полгода так уже
>чтобы сэкономить 32 КБ памяти
Меня не возьмут в бункер, в этом мире и так порядочно людей которые заслуживают эвакуации в убежище 101 больше чем я и многие другие, потому до твоего варианта я не доживу
Ну я вот с клодиком щас проектирую один любопытный бэк на джаве с хитрой rls, увы, чтобы довести диздок до ума и синхронизировать фичи - я потратил прям немало токенов, пару недельных лимитов прошки точно, с полным сопровождением с моей стороны. И это только на диздок. Так что пока не верю в такой расклад, но потенциал виден серьёзный.
>>1086851
>Куда ж это годится?
Мне годится, потому как эти данные это разного рода статические идентификаторы привязанные к конкретному типу, и очень удобно получить их без typeof. Полный плюс вайб.
>И всё также - нахуя брать строго типизированный сишарп и максимально отпиливать от него типизацию?
Где ты увидел максимальное отпиливание? Я углы срезал.
>Это точно не решается без рефлексии
C# настолько хороший язык, что можно хоть на каждый конфигурационный файл такого рода насрать кодогенерацией, или использовать il генерацию, или вообще деревья выражений ебануть, можно даже захардкодить все свичами, но я предпочитаю вариант попроще, попонятнее, побыстрее в реализации.
>Вызов метода по имени из конфижного текстового файла это пиздос и источник поломок на многие месяцы вперед.
Что именно ты видишь источником для поломок? Ну назови просто, при каком варианте я, если задамся целью обеспечить стабильность работы через механизм рефлексии - ну никак не узнаю что обьект не реализовывает метод, или что обьекта не существует? Валидация механизма умещается в 1 тест, который прогонит все конфиги. Конечно, ты можешь сказать - "рефакторинг сломает связь" и будешь прав. Но от рантайм беды меня убережет буквально 1 простейший тест, который прогонит конфиги и их зависимости. Это каким-то значительным образом отличается от компалйтайм ошибки, когда сгенерированный код ссылается на невалидное поле/метод? По моему-никаким значительным образом не отличается. А еще - я могу менять эти конфиги непосредственно при исполнении приложения, что выгодно их отличает от хардкода еще и в таком аспекте.
>В юнити префабы и сцены не yaml? Как считаешь, то что с ними творится можно назвать сериализацией и десериализацией? Я считаю да, это она и есть в самом чистом виде.
Я сильно сомневаюсь, что значения yaml сериализатор ставит рефлексией, по крайней мере net либа yaml сериализации использует деревья выражений, что по факту является кодогенерацией.
>Слишком легко ломаемое, слишком плохой перформанс
Который ты придумал и свято в него веришь. Еще раз - рефлексия применяется у меня единожды для каждого отдельно взятого случая применения. Затем - я использую кеш и скомпилированные делегаты, что приводит к тому что я не использую рефлексию ни для чего, кроме построения кеша, который затем является основой для отработки логики.
>в нетипизированном, где любой ссылочный обьект это хэшмап
>нормальных языках, производительных, с настоящей типизацией
Насколько я понимаю, C# (.NET) является языком наподобие Java (JVM). Т.е. у него все те же проблемы тяжёлой виртуальной машины с ненастоящей типизацией и ненастоящими объектами, которые есть в любой виртуальной машине. Unity Technologies создали свой форк C# с урезанным функционалом, чтобы костылями заделать эти проблемы, но вышло как всегда - "deprecated prealpha" или как они там свои технологии называют...
>в этих языках можно кешировать
Кэширование доступно любому языку, это не зависит от способа выполнения (хоть камешками на песке выкладывай состояние виртуальной машины на 1-мерном клеточном автомате).
>затем их очень дешево инвокать, потому что методы - часть типа
В Godot 4 на GDScript тоже есть тип Callable, который можно хранить в переменной и очень дёшево вызывать (дёшево относительно поиска по строковому имени). Но это не касается темы.
>Поэтому я выбираю с# для скриптов
Т.е. ты признаёшь, что C# - это скриптовая фигня?
>мейби с вводом в строй 26 стандарта
Внутренности Godot пока что на C++ 17 кроме одной папки с Windows, которая на C++ 20 теперь:
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-1/#windows
>...this integration would’ve only been feasible in C++20, whereas the Godot codebase uses C++17 at time of writing.
>...isolate the relevant Windows code to C++20, while keeping the rest of the codebase untouched.
Я на 99% уверен, что они не обновляют версию C++ ради стабильности. Потому что новые версии, как обычно, нестабильное говно, которое некому всерьёз тестировать. Ну а Unreal Engine вообще не настоящий C++ использует, а какой-то там специально сделанный форк (как и костыль-C# в Unity).
>я использовал рефлексию чтобы: ... Примерно такой список
Ты отдаёшь себе отчёт, что компьютерные игры создаются людьми более 60 лет, и всё тобой перечисленное в 99.9999% играх не требовалось и не использовалось? Тебе никогда не кажется, что ты делаешь что-то лишнее, избыточно усложняя то, что можно было сделать намного проще? Интересно даже, какие такие игры ты делаешь, что ты вынужден прибегать к подобным "трюкам" (фактически - грязным хакам, которые едва держатся и могут отлететь в любой момент).
> Т.е. у него все те же проблемы тяжёлой виртуальной машины
Какие
> с ненастоящей типизацией и ненастоящими объектами, которые есть в любой виртуальной машине.
Что это блять значит? Что такое настоящий тип и ненастоящий?
> чтобы костылями заделать эти проблемы
Какие проблемы? Перечисли.
Ах да сразу вкину - моно они взяли не чтобы что-то заделать, а для кроссплатформенности в те времена.
>Насколько я понимаю
Плохо понимаешь, хз как там в джаве, но NET уже очень давно jit-компилируемый язык, прям супер давно.
>ненастоящей типизацией
Все настоящее. Можешь простые бенчи посмотреть, произвидительность на всяком бэнчмарк говне сравнима с плюсами. В реальных кейсах, с gc да со всякими баундсчеками конечно не то пальто будет, но сильно побыстрее интерпретируемого говна от хуана.
>Кэширование
Брух, ну куда ты лезешь. Ну не знаешь ты с# и о каком конкретно кешировании речь - зачем влезать в разговор со своим особо ценным
>тип Callable
Это годотовский делегат, и он к теме обсуждения никаким боком не относится
>Т.е. ты признаёшь, что C# - это скриптовая фигня?
C# настолько хорош что ты на нем можешь писать что угодно, лучшее тому доказательство - существование Xenko/Stride. Собственно и как скриптовый язык, у которого за спиной вагон библиотек для хайлоад энтерпрайза - он тоже отличный.
>Тебе никогда не кажется, что ты делаешь что-то лишнее, избыточно усложняя то, что можно было сделать намного проще?
Оно кажется сложным, только когда я подсвечиваю сложности. Код, который я пишу благодаря этим "грязным хакам" - получается очень простым, легко поддерживаемым, легко понимаемым, и не слишком сложно тестируемым. Я просто фокусник, который любит попиздеть о том как я на самом деле "распиливаю" человека или достаю кролика из шляпы.
>Какие
Попробуй как-нибудь написать виртуальную машину на досуге. Только сначала почитай про устройство процессора, как он взаимодействует с оперативной памятью и т.д. Интересная тема, каждому программисту стоит ознакомиться, даже если ты веб-мартышка. Конечно, старые популярные виртуальные машины сильно оптимизированы, но есть фундаментальные проблемы, которые просто нельзя исправить.
>Что такое настоящий тип и ненастоящий?
Почитай обсуждение. Там анон говорит, что C# якобы лучше, потому что он "настоящий".
>моно они взяли
Речь про ill2cpp/burst или как оно там называется. Мутная тема. По сути это транспилятор "C# у нас дома" -> "C у нас дома", или что-то такое. Лучше бы они вернули в движок тот скриптовый язык, который у них был когда-то... как его называли, UnityScript? Что-то наподобие "JavaScript у нас дома". Большинству ассетфлипов на Unity нет никакой необходимости выходить за рамки JavaScript.
>jit-компилируемый язык
Значение знаешь? JIT - "Just In Time compilation" - "компиляция в последний момент". То есть, представь себе паровозик, который укладывает рельсы прямо перед собой - сначала доски, потом обрезки рельс, потом болты вкручивает, проезжает 1.5 метра вперёд и укладывает новые доски - вот это и есть "JIT компиляция". Преимущество JIT в том, что один и тот же код выполняется на разных платформах - представь, что у паровозика разные типы досок и рельс, которые он выбирает в зависимости от грунта впереди дороги. Недостатки сам понимаешь.
>существование Xenko/Stride
Да? И почему ты сидишь на гнилом (deprecated) Unity, а не на стильном-модном-молодёжном Stride?
>вагон библиотек для хайлоад энтерпрайза
Это не для твоих игрушек написано...
>очень простым, легко поддерживаемым, легко понимаемым, и не слишком сложно тестируемым
Придётся поверить тебе на слово, потому что доказать ты всё равно не сможешь (игор-тонет)...
> Попробуй как-нибудь
Забавно, но это именно то, что тебе стоит посоветовать.
Тип - это чисто компайл тайм понятие. Рантайм мы просто читаем память по какому то адресу и чето с ней делаем.
Разве что ссылка на vtable(и в случае c# более) в заголовке класса это единственный огрызок от типов что остается в рантайме.
Нет типов настоящих и ненастоящих.
> Почитай обсуждение. Там анон говорит, что C# якобы лучше, потому что он "настоящий".
Я хз кто че говорит, я твое сообщение прочитал и ты термин юзал.
> Речь про ill2cpp/burst
А это они взяли чтобы перформанс вытягивать, а не чтобы что-то там чинить.
> Большинству ассетфлипов на Unity нет никакой необходимости выходить за рамки JavaScript.
Есть. Я слабо представляю даже простую игру на жс. Игры довольно сложные и важно чтобы кодовая база была устойчива к изменениям без поломки половины игры.
>Недостатки сам понимаешь.
Недостатки, я так понял, заключаются в том что у jit есть адаптивная оптимизация, а у aot ее нет. Но это трудно назвать недостатком, я бы даже сказал наоборот, это полный достаток. Впрочем - у c# уже очень давно есть АОТ компиляция, для тех кто хочет честную производительность.
>Да? И почему ты сидишь на гнилом (deprecated) Unity
А вот и не угадал. Я сижу на godot 3.6 mono. Stride просто пример, где движок полностью c#, без плюсового ядра.
>Это не для твоих игрушек написано...
Это написано для тех, кто знает как применить то что написано
>Придётся поверить тебе на слово, потому что доказать ты всё равно не сможешь
Уже бегу показывать ключ от квартиры где деньги лежат двачерским дегродам, для такой аудитории ничего не жалко
Пипец, с какими шизофрениками в одном треде сижу...
Даже страшно становится, какие вы там игры-то делаете?..
>Тип - это чисто компайл тайм понятие.
>Нет типов настоящих и ненастоящих.
Сразу видно человека, который никогда не интересовался устройством процессора, не пытался писать код на ассемблере, и не разбирался, почему новейший быстрый процессор может оказаться медленнее в задаче, с которой легко мог справляться более старый, более медленный процессор. Сам концепт "типизации" возник лишь благодаря тому, что он глубоко зарыт в устройство процессоров и сказывается на их ассемблерах, а уже потом этот концепт был дополнен и расширен в новых языках более высокого уровня. Т.е. в реальности есть типы, с которыми работает процессор напрямую, а есть типы, которые твой язык конструирует из базовых типов процессора. "Язык с динамической типизацией" означает лишь то, что язык (интерпретатор или виртуальная машина) выбирает подходящие инструкции по определённым признакам. По-настоящему отказаться от типов на современных процессорах - значит нанести очень большой ущерб производительности, ведь абсолютное большинство нововведений связаны с конкретными типами данных, а потолок возможностей одного ядра "без типов" уже давно достигнут (т.к. просто не выходит повышать частоту процессора ещё больше).
>Я слабо представляю даже простую игру на жс
Многие игры, которые мне в своё время очень понравились и даже полюбились, написаны на ECMAScript (либо JavaScript в браузере, либо ActionScript на Flash). И играл я в них на очень слабом железе, 1 GB RAM и 2 ядра 1 ГГц... Так что ты сильно заблуждаешься, если думаешь, что для хорошей игры нужен производительный язык. Для хорошей игры нужен хороший дизайн, хорошая графика, хороший сюжет и хорошая озвучка, но никак не производительность кода и даже не полное отсутствие багов в коде. Баги и тормоза игроки терпят, а плохие игры - удаляют.
>двачерским дегродам
Вообще-то я тоже годосподин, и зашёл сюда просто потому что в Godot-треде активность упала, а мне сраться с юнити-детьми даже интереснее, чем свою игру делать. А ты тут что делаешь? Не желаешь вернуться в Godot-тред? Печально, что ты на старой версии и привязан к C#, но мы любим всех...
Ты же тот, у которого мобильная ММО-дрочильня? Тогда понятно, зачем тебе нужны те странные выкрутасы с поиском методов по строковым именам... Сочувствую тебе и желаю поскорее закрыть старый проект и начать что-нибудь новое. Лучше отпустить старое, которое причиняет тебе страдания.
> Сам концепт "типизации" возник лишь благодаря тому, что он глубоко зарыт в устройство процессоров и сказывается на их ассемблерах, а уже потом этот концепт был дополнен и расширен в новых языках более высокого уровня. Т.е. в реальности есть типы, с которыми работает процессор напрямую
Мы говорим про языки, или не? Ясен хуй в проце есть "типы" но они привзяаны к конкретным инструкциям в проце, языку тут поебать.
4 байта в памяти это 4 байта в памяти и больше ничего.
От того что ты выполнишь команду "сложи 2 целых числа" закинув в один из регистров эти 4 байта - эти 4 байта не перестанут быть всего лишь 4 байтами в памяти. Которые ты можешь спокойно закинуть в операцию над флоатами.
У тебя и в С++ компилятор, и C# компилятор одинаковые инструкции сгенерит.
Поэтому никаких ненастоящих типов нет.
> По-настоящему отказаться от типов на современных процессорах - значит нанести очень большой ущерб производительности
Это впринципе невозможно, если мы говорим про базовые инструкции проца, какой ущерб если вообще ничего не будет?
> ведь абсолютное большинство нововведений связаны с конкретными типами данных, а потолок возможностей одного ядра "без типов" уже давно достигнут (т.к. просто не выходит повышать частоту процессора ещё больше).
Какой потолок, какие "без типов", если алу это первое что у тебя в проце появилось вообще?
> Многие игры, которые мне в своё время очень понравились и даже полюбились, написаны на ECMAScript (либо JavaScript в браузере, либо ActionScript на Flash).
Это говорит о чем? О том что вприцнипе на этом можно сделать примитивную веб игру? Пожалуй можно.
Говорит ли это о том что это азебись для нормальных проектов?
Это говорит о том, что это вариант покруче, чем например юнити?
>Это каким-то значительным образом отличается от компалйтайм ошибки
А зачем изобретать велосипед на костылях, когда можно купить готовый?
>могу менять эти конфиги непосредственно при исполнении приложения
Godot поддерживает hot reload для GDScript (на счёт C# не знаю) и также стремится обновить все tscn/tres данные в работающей игре. Не всегда успешно, почему-то, но это не важно (скорее всего я что-то не то нажимаю, лол). Из моего опыта: мне как-то проще перезапустить рантайм Godot с маленьким локализованным тестом игровой логики, чем сделать hot reload и надеяться, что это не будет отличаться от перезапуска. Потому что, как бы ты ни старался сделать подгрузку данных бесшовной, подгрузка данных по ходу игры - это не то же самое, что загрузка данных с нуля. Достаточно хоть одному биту памяти быть не таким - и всё поломается, а ты потом будешь сидеть и ломать голову, откуда эта ошибка взялась, если весь твой код написан безошибочно...
Короче: лучше запустить игру заново (или вторую параллельно первой), чем подгрузить изменённые данные в уже запущенную и надеяться, что ничего не сломается из-за какой-нибудь неуловимой ошибки "одного бита памяти". В особенности если у тебя не серверная платформа с ECC RAM, а обычный "геймерский" ПК.
>примитивную веб игру
>нормальных проектов
Ну вот опять началось:
>кококо не хочу кликать мышкой на печеньку, не хочу видеть как numbers go up, нет доставляет мне это дофамина, ааааа дайти мне нормальную игру а не примитивную
>оооо, вот это да, вот это рейтрейсинг, вот это тени, ммммм, струя 240 фпс в лицо, как приятно, прямо фонтан эмоций, дофамин заменил мне кровь, вот это да, ааааах, аааах
Может, тебе лучше было бы в кинематограф устроиться, а не играми заниматься?
Причём тут графон ваще? Ты сам во что играешь, в куки кликер или во что-то ещё?
>Лучше отпустить старое, которое причиняет тебе страдания.
В четверке верстать интерфейс не сильно удобнее, это единственное что мне реально причиняет в годоте страдание и не фиксится никакими нейронками, более отвратительный UX редактора сложно представить, где-то на уровне гимпа
>Причём тут графон ваще?
При том, что основная заслуга движков уровня Unity - это готовый пайплайн для реалистичной 3D графики и физики. Сделать более сложную 2D игру можно без такого движка, поддержка 2D в движках уровня Unity - это чтобы ньюфагов и прочих соло индюков заманивать. Даже в Godot поддержка 2D - это скорее побочный эффект реализации сложного GUI, которому необходимо 2D, а не основной приоритет: Godot изначально и всю дорогу был 3D движком для реалистичной графики, а 2D долго улучшали по запросам индюков. Можно сколько угодно ругать 3D рендерер Godot, но он всегда был и остаётся основным приоритетом движка.
Поэтому фразу "нормальный проект на Unity" я понимаю как "фотореалистичная 3D игра".
>Ты сам во что играешь
Я во многое играл... Всего не вспомню, но было и 3D, и 2D, и ASCII, и чисто текстовые игры, и консольные на эмуляторах, и почти все жанры попробовал. Но я надолго в одной игре обычно не задерживаюсь, поиграл несколько часов/дней и уже как-то не хочется - ищу что-нибудь другое, даже если не прошёл до конца. Бывало и так, что затягивало, так что "игровая зависимость" я знаю не по наслышке... и про "эффект тетриса" тоже. И имея такой разнообразный опыт я могу сказать с полной уверенностью: для полноценной увлекательной игры не важен ни язык, ни движок, ни тип вывода информации на экран, но если тип вывода - графика, то графике нужно быть гармоничной.
Сраться за языки, за паттерны, за движки и прочие технологии - это весело, но к разработке игр как таковой имеет мало отношения. От того, что ты там под капотом используешь, игроку ни лучше, ни хуже не будет. Важно только то, по каким правилам ты будешь взаимодействовать с игроком и что будешь ему выдавать на устройства вывода. А играть можно и без монитора вообще, используя принтер для печати игровой информации на бумаге, выполняя код прямо на языке этого принтера:
http://duckduckgo.com/?q=can+you+write+a+videogame+on+PostScript+and+embed+into+printer
>А играть можно и без монитора вообще, используя принтер
Или аудио. Есть аудиоигры, кстати. Для слабовидящих и слепых.
В общем, технологии для игр нужны, но не являются определяющими.
>В четверке верстать интерфейс не сильно удобнее
Тебе, наверное, понравятся нововведения в 4.7:
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-1/#gui
В остальном же: если у тебя никогда не было опыта с WYSIWYG-редакторами GUI, то тебе просто нужно почаще читать документацию и больше экспериментировать, пока не откроешь для себя то, что тебе удобнее делать; а если ты переходишь с HTML/CSS или любого другого GUI, то придётся потерпеть, пока привыкаешь к особенностям нового. Система GUI в Godot реально мощная и покрывает все потребности большинства игр, а те, что не покрываются базовыми нодами - легко слепить с нуля на GDScript из базовых нод, но переходящим с других GUI, конечно, может быть непривычно.
>не фиксится никакими нейронками
Возможно, твоя проблема в том, что ты пытаешься найти "фикс" (костыль) там, где тебе нужно просто привыкнуть к тому, как принято обращаться с инструментом. Представь, что тебе дали молоток забивать гвозди, а ты говоришь "это неудобно, хочу черпать молотком как ложкой" и начинаешь мастерить сложную систему их шестерней, верёвок и рычагов, чтобы преобразовать черпающие движения как у ложки в удары молотком по гвоздю; а потом приходишь к мастерам и жалуешься, что молотком неудобно пользоваться даже с системой из шестерней и рычагов. Не смешно ли? Если бы ты просто заставил себя несколько дней бить молотком как положено, ты бы привык и научился делать так, как удобнее всего. А не тратить время на лишние костыли, которые не решают проблему.
>более отвратительный UX редактора сложно представить
Ну, не знаю. Я, наоборот, не встречал UI/UX лучше Godot. В этом Godot как Blender: при самом первом знакомстве ты можешь опешить от обилия непонятных кнопок, надписей, менюшек и субменюшек, но когда поработаешь в нём через силу и привыкнешь, начинаешь хотеть, чтобы во всех остальных программах было так же, как в нём.
Анон, я до годота работал с юнити и это не просто небо и земля, это блять мантия и геоцентричная орбита по разнице в уровне удобности редактора. В целом, терпимо всё, но верстать, особенно сложные интерфейсы со всякими рисованными рамочками и прочими найнпатчами - просто пиздец. И этот пиздец не передать текстом. Тем, кто работал с нормальными редакторами - будет больно физически. И привыкнуть к этому невозможно, только затерпеть.
>нововведения в 4.7
Как были элементы интерфейса прихуячены гвозями, так и остались, если сравнивать с dockable интерфейсом юньки (с бесконечными дублями окон и фиксаторами на обьектах) это конечно смешно. Я знаю что это опенсорс, и в целом претензий не имею, но смешно коупить тоже не буду. Ну и да, в тройке к тому же эта проблематика только усугубляется, но не так чтобы я видел наглядный сдвиг в четверке, просто пофиксили часть бесячей хуйни и на этом все, а сам интерфейс как был хуитой непотребной, так ей и остался. Разве что среди прочих foss инвалидов годот наверное лучший.
>Анон, я до годота работал с юнити и это не просто небо и земля, это блять мантия и геоцентричная орбита по разнице в уровне удобности редактора
Это правда. После годота срунити просто неюзабельное говнище, застрявшее в 90-х.
> При том, что основная заслуга движков уровня Unity - это готовый пайплайн для реалистичной 3D графики и физики.
Это конечно заебись, но это не основная заслуга.
Основная заслуга - это экосистема для разработки.
Там и редактор(сцены, объекты, конфиги) есть который можно расширять и кастомизировать легко, намного легче чем делать свои нативные тулзы.
Система сборки проекта под любые платформы.
Интеграция в целом графического апи, звукового, загрузка выгрузка ресурсов.
Готовые системы вроде ui, партиклов, аниматора, поддердка всевозможных форматов.
И главное всё это достаточно хорошо отлажено, достаточно унивресально чтобы разраб с одного проекта в другой мог терпимо перекатываться.
> Сделать более сложную 2D игру можно без такого движка
Зачем тебе всё что я перечислил выше писать самостоятельно, когда оно готовое есть?
>, поддержка 2D в движках уровня Unity - это чтобы ньюфагов и прочих соло индюков заманивать
Миллионы 2д игр на юнити в проде, в том числе сложных и объемных: ну да, пошли мы нахуй.
> Поэтому фразу "нормальный проект на Unity" я понимаю как "фотореалистичная 3D игра".
Ну это чисто твоя шиза. Абсолютно большая часть игр на юнити имеют стилизованную или 2дшную графику. Мобилки, инди сегмент - там доминирует югити, много там фотореалистичных игр. Для фотореализма берут анрил.
> Сраться за языки, за паттерны, за движки и прочие технологии - это весело, но к разработке игр как таковой имеет мало отношения.
Так ты попробуй игры поделать лол.
Игроку правда поебать что внутри.
А вот у разраба - от того какие он решения по разработке будет принимать, какие инструменты использовать - от этого напряиую зависят сроки разработки.
Сделать игру быстрее наверное всё же лучше чем дольше, или ты не согласен?
А, я вспомнил, ты же ОКРное шизло, которое постоянно двигает куда-то окошки и все ломает. Вместо того чтобы просто работать в редакторе.
Когда количество ассетов превышает четыре тысячи - приходится часто прыгать по папочкам. Но безигорному, конечно, не понять
Мне нравятся те 90, в которых застряла юнити. Смузихлебное говнецо от хуана ощутимо хуже
Никаких 4000 ассетов у тебя конечно нет, а игру с парой сотен ассетов я делал и никаких проблем с папочками там нет, а кроме того есть легчайшие способы упростить это тул скриптами, часто готовыми аддонами.
Ах да, и конечно необходимость вручную куда то что то таскать есть только у тупых ассетотаскателей, в моей игре все это процедурненько подгружалось-генерилось
У меня не так много опыта в создании GUI, но перечислю:
1. HTML/CSS: я печатал весь код руками в текстовом редакторе и очень сильно мучился из-за того, что описанные в документации свойства либо не работают совсем, либо работают не так, как описано, либо с чем-то конфликтуют, что-то там перекрывают и т.д. Привязывать события GUI к обработчикам на JS тоже было крайне неудобно. Я слышал про множество GUI фреймворков поверх базовых возможностей и также слышал про WYSIWYG-редакторах, но не смог определиться с тем, что мне следует выбрать из этого зоопарка кривых костылей и тяжёлых велосипедов. Пытался вкатиться в это дело несколько раз на протяжении многих лет, если что, и сверстал кучу разных страничек.
2. Unity: в Unity я пытался вкатиться несколько раз, и каждый раз там не было встроенного GUI, вот совсем. Неужели наконец-то встроили? В любом случае, Unity всегда предлагала на выбор огромное количество ассетов для GUI, из которых непонятно, что выбирать. А базовая Unity без ассетов может только голый Label и Button сделать, да и те нужно через код на C# ковырять. Я так и не смог разобраться с GUI в Unity даже с туториалами, а рисковать, ища и устанавливая чужие костыльные велосипеды из ассет-стора мне не хотелось. Собственно, мой опыт подкрепляется огромным количеством инди-игр на Unity с абсолютно уродливым, кривым и глючным GUI, который часто ещё и тормозит сильнее, чем основная игра с фотореалистичной графикой, лол. Я вообще не понимаю, за что ты её нахваливаешь (какой ассет скачал?).
3. Delphi/Lazarus: это эталон WYSIWYG-редактора GUI под Windows и Linux как минимум, а то и под Android тоже. Лучше редакторов я не пробовал, кроме, собственно, Godot (но о нём потом). Позволяет с лёгкостью набросать именно то, что ты хочешь увидеть в своём приложении, и так же легко и быстро соединить события виджетов с обработчиками в коде. Также позволяет создавать свои собственные виджеты с уникальным внешним видом и поведением, наследуясь от стандартных - но с одним существенным для меня недостатком: поскольку Pascal - компилируемый язык, IDE не способна быстро подхватить разрабатываемый компонент или обновить его состояние. Как минимум Lazarus требует собирать IDE из исходников для встраивания нового компонента в палитру, а про Delphi не помню уже. Да, разумеется, Pascal очень быстро компилируется, и IDE пересобирается за секунду, но всё равно это раздражает и не даёт комфортно делать новые виджеты. Но достойной альтернативы Delphi/Lazarus (для нативного GUI на Windows/Linux) я не нашёл - везде какие-то проблемы.
4. Godot: это просто шикарно, как будто переписали Delphi с нуля, добавив возможность разрабатывать новые компоненты на живом движке - совсем без пересборки из исходников, без компиляции, даже без перезапусков. Ты просто берёшь, и делаешь какие угодно новые виджеты - буквально какие угодно. Реально. При этом твои нововведения, даже написанные на GDScript, органично интегрируются в уже имеющуюся экосистему Godot, словно они там всегда были. При этом нет никаких костылей и велосипедов как с HTML и Unity - нет необходимости качать какие-то заплатки от третьих лиц, ты просто сел за комп, открыл редактор и шлёпаешь свой интерфейс почти как в Delphi, точно так же легко и просто соединяешь события с кодом, но при этом в любой момент можешь взять, и собрать свой собственный компонент, не отвлекаясь ни на что, не выходя из состояния потока, и сразу же использовать свой новый компонент в работе над своим интерфейсом. Шикарно, просто шикарно. Я сомневаюсь, что кто-то смог сделать что-то лучше интерфейса Godot. При всём этом он и выглядит вполне элегантно. Небольшие косяки есть, конечно, особенно в плане взаимодействия с операционкой, но оно и понятно. Преимущества перешивают недостатки - неудивительно, что на Godot всё чаще делают GUI приложений, никак не связанных с играми. Если про Godot узнают больше людей, и разрабы начнут делать официальные "только GUI" сборки (чтобы не было лишнего 3D, физики и т.п.), может, мы увидим больше новых прикладных приложений, написанных на Godot... Хотя у него есть оверхед из-за того, что он не использует нативные виджеты ОС, но для некоторых приложений это не критично, особенно если важен одинаковый GUI на разных платформах.
> HTML/CSS: я печатал весь код руками в текстовом редакторе и очень сильно мучился из-за того, что описанные в документации свойства либо не работают совсем, либо работают не так, как описано, либо с чем-то конфликтуют, что-то там перекрывают и т.д. Привязывать события GUI к обработчикам на JS тоже было крайне неудобно. Я слышал про множество GUI фреймворков поверх базовых возможностей и также слышал про WYSIWYG-редакторах, но не смог определиться с тем, что мне следует выбрать из этого зоопарка кривых костылей и тяжёлых велосипедов. Пытался вкатиться в это дело несколько раз на протяжении многих лет, если что, и сверстал кучу разных страничек.
Так это ты просто не осилил. Весь фронтенд на этом сидит, включая мобайл.
> Unity: в Unity я пытался вкатиться несколько раз, и каждый раз там не было встроенного GUI, вот совсем. Неужели наконец-то встроили? В любом случае, Unity всегда предлагала на выбор огромное количество ассетов для GUI, из которых непонятно, что выбирать. А базовая Unity без ассетов может только голый Label и Button сделать, да и те нужно через код на C# ковырять. Я так и не смог разобраться с GUI в Unity даже с туториалами, а рисковать, ища и устанавливая чужие костыльные велосипеды из ассет-стора мне не хотелось.
И тут не осилил лол. Ты серьёзно аргументируешь своим неосиляторством лол? Если не знаешь что взять, не важно для какой цели - узнай от шарящих челов или сформулируй требования.
В юнити целых 2 юи системы - одной лет 10+, с версткой врчную якорями, другая - HTML/CSS-likeдаже 3 - одна легаси. Так, на всчкий случай)
> да и те нужно через код на C# ковырять.
Верстка и программирование это разные вещи. Версткой занимаются не программисты как правило.
>Собственно, мой опыт подкрепляется огромным количеством инди-игр на Unity с абсолютно уродливым, кривым и глючным GUI, который часто ещё и тормозит сильнее, чем основная игра с фотореалистичной графикой, лол. Я вообще не понимаю, за что ты её нахваливаешь (какой ассет скачал?).
Во-первых прямость гуи заивисит от прямоты верстки.
Во-вторых это просто пиздёжь, хз.
> Delphi/Lazarus: это эталон WYSIWYG-редактора GUI под Windows и Linux как минимум, а то и под Android тоже.
То-то вся индустрия с этого говна перешла на хтмл везде(кроме геймдева - и то даже в нем уже есть небольшая тенденция на переход). А надо было просто тебя слушать.
Бизнес захватывает эффективность. Если ты делаешь что-то эффективнее других - ты начнешь их выдавливать с рынка.
Пока твои руки-крюки таскают кнопки по экрану и чинят полетевшую верстку в окне которое ты год назад делал или копипастят куски окошка в другое окошко а от оверлейных элементов общих для разных окошек последние волосы выпадают - базовички просто открывают код разметки и сразу видят всю картину.
Дооо, такое чувство что ты троллишь и в интернет не заходишь и не видишь как у всех этих эффективных пизнесменов везде верстка разваливается.
>Весь фронтенд на этом сидит, включая мобайл.
Поэтому с вебом и мобилками всё очень плохо...
>аргументируешь своим неосиляторством
Если твой инструмент настолько недружелюбен к новичкам, то это проблема инструментов и его разработчиков, а не новичков. Ты не можешь говорить "этот инструмент хорош" если для его комфортного использования придётся бегать по каким-то форумам и
>узнай от шарящих челов
Почему ты вообще написал "узнай у челов", а не "открой документацию"? Неужели чисто по документации не разобраться? Я с Godot по официальной документации разобрался. Это многое говорит о дружелюбности Godot к новичкам, и поэтому он хорош.
>Верстка и программирование это разные вещи.
В энтерпрайзе и ААА - наверняка так и есть, специальный кабанчик на подскоке с какой-нибудь смешно звучащей специальностью вроде "кнопкомаляр" (меняет HEX-значение свойства color в классе Button и ничего кроме этого не умеет делать). А в маленьких командах и тем более если ты одиночка - ты делаешь всё сам, и тебе важно, чтобы твой инструмент не вставлял тебе палки в колёса лишними альт-табами, ожиданием, пока код скомпилируется, редактор перезапустится и т.п. Короче, ты должен чувствовать себя так, будто едешь на велосипеде, а не скачешь по минному полю.
>прямость гуи заивисит от прямоты верстки
А прямота вёрстки напрямую зависит от того, как хорошо лежит в руке твой инструмент и насколько он стабилен. С хорошим инструментом работа хорошо идёт, тогда как с плохим ты больше времени тратишь на то, чтобы починить этот инструмент и заставить его работать так, как тебе нужно. Если большинство не справляются с инструментом, то он плохой.
>это просто пиздёжь
Ты просто мало тестировал чужие инди-игры на юнити.
>вся индустрия перешла
Delphi платный и очень дорогой. Lazarus долгое время был глючным и малоизвестным. А преимущество HTML/CSS в том, что веб-сайтов наделали намного больше, чем людей на планете, и веб-макак тоже много - следовательно, любой кабан может взять любую из этих веб-макак и заставить делать своё приложение. Качество технологии, удобство IDE и прочие детали менеджеров в данном случае вообще не волнуют - им главное получить какой-то результат с минимальными затратами, желательно взяв наивных студентов вместо тех, кто знает цену своего труда. Аналогично и с геймдевом - если веб-макака устала делать веб-сайты под ключ, и хочет сделать игру, она будет искать движок с HTML/CSS/JS внутри, а не то, что принято использовать в геймдеве.
Такое чувство, что было бы странно, что куча людей юзаеют хтмлцсс и делают на нем проекты разного масштаба, причем успешно, и тут выходишь ты и говоришь, что вообще все они ошибаются.
Предположим. А как ты понял, что твой способ лучше? Ты пробовал в разных проектах применять, прикидывать затраты времени на разработку прототипа, итерации, поддержку, у тебя за плечами много опыта для сравнения?
Или просто потому что ты не осилил хтмл, поэтому?)
> в интернет не заходишь и не видишь как у всех этих эффективных пизнесменов везде верстка разваливается.
Ну бля сложно все девайсы предусмотреть, особенно если сайт большой, бывают где-то недочеты.
Ты-то почему не сделал лучше и не научил всех? Не охота просто?) Влт если бы я знал как лучше - я бы уже монетизировал этот навык+знания, при том что это не моя область вообще.
>Пока твои руки-крюки таскают кнопки по экрану
Ты против WYSIWYG в целом что ли? Вот это лол.
>чинят полетевшую верстку в окне которое ты год назад делал
Если версию движка не обновлял - то вина в твоём говнокоде.
Если обновлял - то о таком в ченджлогах предупреждают.
>копипастят куски окошка в другое окошко
Ещё не открыл для себя кнопку "сохранить ветку как сцену"?
>оверлейных элементов общих для разных окошек
Чиво? Это где ты в Godot нашёл? Опять твой костыль?
>просто открывают код разметки и сразу видят всю картину.
Верстать через код - последнее дело, особенно в играх.
Ладно, открою секрет: ты можешь делать GUI... через код!
Просто спавнить Control-ноды в дерево из своих скриптов.
> Поэтому с вебом и мобилками всё очень плохо...
Что именно всё? На рынке веб и мобилки это доминирующая форма ПО.
> Если твой инструмент настолько недружелюбен к новичкам, то это проблема инструментов и его разработчиков, а не новичков. Ты не можешь говорить "этот инструмент хорош" если для его комфортного использования придётся бегать по каким-то форумам и
Ты говоришь слово "проблема" и "хорош", но эти слова очень контекстуальные.
Для тебя наверное проблема, если у тебя бюджет на вкат в инструмент - 1 день - действительно, этого очень мало чтобы разобраться.
Для того, кто готов потратить ощутимо больше времени на изучение инструмента(в целом кого угодно кто занимается разработкой игр много, не по вечерам пятницы раз в неделю) - это не проблема, а сам инструмент хорош и даст огромный выигрышь на дистанции.
> >узнай от шарящих челов
> Почему ты вообще написал "узнай у челов", а не "открой документацию"?
Потому что инструмент это инструмент, документация объясняет как им пользоваться, а не что тебе делать в какой ситуации.
На юнити делать игры по документации юнити ты не научишься вообще никак.
На годоте тоже, и я могу это сказать даже не глядя в документацию.
Что где на практике лучше - ты узнаешь ищ практики и ресерча чужих практик которые применяют.
> В энтерпрайзе и ААА - наверняка так и есть, специальный кабанчик на подскоке с какой-нибудь смешно звучащей специальностью вроде "кнопкомаляр" (меняет HEX-значение свойства color в классе Button и ничего кроме этого не умеет делать). А в маленьких командах и тем более если ты одиночка - ты делаешь всё сам
Бред. Я когда в маленькой команде работал на 7 челов - мы джуна сделали верстальщиком.
> и тебе важно, чтобы твой инструмент не вставлял тебе палки в колёса лишними альт-табами, ожиданием, пока код скомпилируется, редактор перезапустится и т.п.
Это важно для кого угодно в любой команде.
> Если большинство не справляются с инструментом, то он плохой.
Где какое большинство не справляются с инструментом?
> Ты просто мало тестировал чужие инди-игры на юнити.
Я и играл во много игр на юнити и делал.
> Delphi платный и очень дорогой.
Это две копейки в масштабах проекта.
> А преимущество HTML/CSS в том, что веб-сайтов наделали намного больше, чем людей на планете, и веб-макак тоже много - следовательно, любой кабан может взять любую из этих веб-макак и заставить делать своё приложение.
А прикинь - ты приходишь к кабану и говоришь - смотри кабан, я могу лучше сделать, разработка будет занимать меньше времени.
Что тебе мешает? Или какому-то другому разумисту? Почему этого не происходит?
> Качество технологии, удобство IDE и прочие детали менеджеров в данном случае вообще не волнуют - им главное получить какой-то результат с минимальными затратами, желательно взяв наивных студентов вместо тех, кто знает цену своего труда.
Каво нахуй, фронтедерам мало платят по твоему?
> Ты против WYSIWYG в целом что ли? Вот это лол.
Довольно часто - да.
> Если версию движка не обновлял - то вина в твоём говнокоде.
А причем тут код и верстка? Ну да ладно, просто практически говоря - когда ты делаешь приложение с гуи, рано или поздно у тебя будет такая ситуация.
> Ещё не открыл для себя кнопку "сохранить ветку как сцену"?
Как ее потом вставлять куда то? Руками?
> Чиво? Это где ты в Godot нашёл? Опять твой костыль?
Я не ебу вообще чем там в годот я его не открывал никогда. Задача - есть какая-нибудь панелька снизу, а по центру ращные окошки меняются. Надо чтобы верстка была согласована. Твои действия?
> Верстать через код - последнее дело, особенно в играх.
Смотря какой код.
> Ладно, открою секрет: ты можешь делать GUI... через код!
Какой именно код? Мне кажется хтмл тут ебет другие варианты по явности и наглядности и гибкости, особено тот ужас что ты поедлагаешь далее
Вообще ничего странного, бабло и маркетинг решают. А хтмл да, не осилил, ну написал базовый рендерер html с++, но там просто геморно все стандарты реализовать чтобы сделать свой браузер, который миллион макак в гугле каждый год дополняют.
>Ты против WYSIWYG в целом что ли?
Это БАЗА, Причем доказанная еще годах в 90-х.
>На рынке веб и мобилки это доминирующая форма ПО.
Потому что большинство юзеров - тупое быдло с мобилой.
>если у тебя бюджет на вкат в инструмент - 1 день
Не поверишь, но люди с СДВГ реально существуют.
>готов потратить ощутимо больше времени на изучение инструмента
Плакать, колоться, но продолжать жрать кактус (ради галлюцинаций)?
>как им пользоваться, а не что тебе делать в какой ситуации
Лол? Если взять, например, огнетушитель, то там чётко написано, для тушения каких типов возгораний он предназначен. Если взять тюбик клея, то там чётко написано, для склеивания каких материалов он предназначен. Если взять Unity... то там deprecated experimental prealpha и куча гнилых ассетов за сотни баксов, которые только усложняют задачу, а не упрощают.
>На годоте тоже, и я могу это сказать даже не глядя в документацию.
Так вот почему ты никак не можешь разобраться с GUI. Ясно-понятно.
>Что где на практике лучше - ты узнаешь ищ практики и ресерча чужих практик которые применяют.
А можно открыть документацию и почитать рекомендованное разрабами:
https://docs.godotengine.org/en/stable/tutorials/best_practices/index.html
>мы джуна сделали верстальщиком
Жестокие люди, глумились над несчастным...
>разработка будет занимать меньше времени
Без людей-специалистов это пока не работает.
>фронтедерам мало платят по твоему?
Меня не интересуют их проблемы.
>>1086914
>>Ты против WYSIWYG
>Довольно часто - да.
Почему тогда Godot, а не какой-нибудь SDL? Чтоб без редакторов.
>А причем тут код и верстка?
Не поверишь, но "вёрстка" - это тоже код, только декларативный.
>рано или поздно у тебя будет такая ситуация
То, что ты не открывал целый год, не может просто так сломаться.
>Как ее потом вставлять куда то? Руками?
Выбрал ноду -> Ctrl+Shift+A -> имя в поиске -> Enter.
Но ты можешь и сделать скрипт для генерации (если это менюшка).
>годот я его не открывал никогда
Ну и чё ты влезаешь-то, не с тобой спорили.
>Задача - есть какая-нибудь панелька снизу, а по центру ращные окошки меняются. Надо чтобы верстка была согласована. Твои действия?
В Godot это можно сделать, например, так (если окна фиксированы):
>BoxContainer
>_ CenterContainer
>_ _ Center1
>_ _ Center2
>_ _ Center3
>_ PanelContainer
Потом просто скрываешь/отображаешь то, что тебе нужно. Всё будет автоматически растягиваться-натягиваться под размер и пропорции экрана. Можно даже настроить так, чтобы оно адаптировалось под вертикальное и горизонтальное положение экрана на мобилках, если твоя нижняя панелька может быть расположена вертикально сбоку (как в некоторых играх).
>Смотря какой код.
Скорее "смотря какая задача". Заполнить меню одинаковыми кнопками - это да, лучше через код. А вот красиво и удобно расположить уникальные кнопки, которые имеют разные формы и разное предназначение - тут только через визуальный редактор. Для примера, основная панель GUI в The Sims выглядит слишком сложной для того, чтобы настраивать её полностью через код (хотя в те времена у них могло не быть редактора GUI), но вот списки предметов с иконками заполняются автоматически через код.
>Какой именно код?
Императивный. Твой HTML - это декларативный код. Но можно сделать GUI полностью на императивном коде. Разница только в том, что декларативный код описывает "что должно быть", а императивный код перечисляет "что нужно сделать". Пример: <div> - это "где-то здесь должна быть какая-то коробка с чем-то" (и дальше движок пытается угадать, что с этим делать), а add_div() - это "добавить коробку с этим содержимым прямо сейчас и прямо здесь" (и движок напрямую выполняет этот запрос как он записан). У каждого подхода свои преимущества и недостатки, однозначно лучшего нет.
Файлы сцен (tscn) в Godot - это декларативный код (но не XML, а что-то вроде INI).
чепуха. програмно GUI создавать проще, быстрее. у меня все создается програмно.
> Вообще ничего странного, бабло и маркетинг решают.
Они дают трафик, а не реанимируют труп.
В крупных компаниях есть ресурсы тестить новые технологие, стартапы могут со старта че хотят брать.
У нас например для новой игры взяли анрил, при том что вся компания на юнити работает.
>>1086919
> Потому что большинство юзеров - тупое быдло с мобилой.
Ой, а ты у нас очень умный я смотрю.
Вебмакаки - тупые. Юзеры - тупые. А кто умный-то, ты что ли?
Ты телефоном не пользуешься кстати? Я вот пользуюсь постоянно. Я даже на дваче с телефона только сижу.
> Плакать, колоться, но продолжать жрать кактус (ради галлюцинаций)?
Какой кактус, какие галлюцинации?
Прибыль и интерес определяет вектор движения, если это сложно - то найдутся те кто осилят, если оно того стоит.
> Лол? Если взять, например, огнетушитель, то там чётко написано, для тушения каких типов возгораний он предназначен.
А у нас огнетушитель или движок или какой-то сложный инструмент? Точно ли на всём в инструкции должны быть описаны все кейсы и цели применения?
На карандаше написано для каких он целей? На ручке написано как ей войну и мир написать? На кирпичах написано какой ими дом строить и как?
Твоя аналогия саморазъебывается за 5 секунд размышлений. Так как ты этого не сделал - я правильно поримаю, что ты менее 5 секунд думаешь что написать?
> Если взять Unity... то там deprecated experimental prealpha и куча гнилых ассетов за сотни баксов, которые только усложняют задачу, а не упрощают.
И сюда же сразу
> Плакать, колоться, но продолжать жрать кактус (ради галлюцинаций)?
Разработка игр это не простое дело, так уж получилось. Чтобы с нуля даже до уровня джуна которыц почти ничего не умеет дойти - нужен год упорной учебы и практики. И никто тебя за ручку вести не будет, нету едино правильного гайда.
> Так вот почему ты никак не можешь разобраться с GUI. Ясно-понятно.
С каким гуи я не могу разобраться?
Я на юнити через якоря умею профессионально верстать, пусть практики и не так много. Разбираюсь в гуи шейдерах.
На хтмл на любительском уровне.
На Qt тоже быдо дело, но это та же чкорная система что и в юнити.
С точки зрения программирования я занимался гуи любой сложности.
Так что не, сорян, в гуи я шарю хорошо.
> А можно открыть документацию и почитать рекомендованное разрабами:
Я не знаю, насколько разрабы годота сами профессионалы в разработке игр, разработка инструмента как бэ не значит, что они шарят в прикладном применении, такие вещи как правило разрабатываются реактивно - есть запрос бизнеса и аудитории - есть решения.
> Жестокие люди, глумились над несчастным...
Это стандартная практика, задачи по верстки часто пдаают на джунов либо на про верстал.
> Без людей-специалистов это пока не работает.
Так у тебя во всяких гос парашах, заводах и нии сидят орды Qt-макак, и даже делфи там практикуют. Чем не устроят?
> Меня не интересуют их проблемы.
Так ты сам сказал про них, что вот берут народ который не знает цену своего труда. На практике фронтендеры часто получают 2х-4х от того что получают делфи и Qt бояре.
> Почему тогда Godot, а не какой-нибудь SDL? Чтоб без редакторов.
Довольно часто - не значит, что всегда. Сцены собирать практика показывает что лучше в визуальном редакторе.
> Не поверишь, но "вёрстка" - это тоже код, только декларативный.
А как верстка может быть говнокодом тогда?
> То, что ты не открывал целый год, не может просто так сломаться.
Да что ты. А то что ты сделал год назад - будет статичным и не будет более трогаться в процссе, не будет изменений которые косвенно на это влияют? Какую нибудь кнопку с ценой переверстали и вышла необходимость внести критичнеы зменения, везде где она есть - могут вылезти проблемы.
> Выбрал ноду -> Ctrl+Shift+A -> имя в поиске -> Enter.
Так ее можно хоть засейвить так, чтобы её реальные инстансы оставались связаны с оригиналом? Один раз изменил - все окна подхватили?
> Ну и чё ты влезаешь-то, не с тобой спорили.
Я увидел бред, я его прокомментировал.
> Потом просто скрываешь/отображаешь то, что тебе нужно.
Слодность гуи большая, мне нужно отделить, а не скрывать.
> Императивный.
Получится говняк.
Они берут анрил не потому что это какая то новая технология, а потому что видят что там много разрабов которых можно будет менять как винтики. При этом все знают, что играки ненавидят анрил 5
Любая вебмакак с интерфейсом справится
>играки ненавидят анрил 5
это они еще юнити или годот не видели...
Любой не справится, растеряется, там урезаный хтмл. Будет как местный шарпоговноед бегать
Разве? Мне казалось наоборот. Да и на godot как-то мало хороших 3д игр, они как бы есть по ним не понятен придел возможностей.
Куда забавнее что даже низшие касты из майкрософт используют прямого конкурента шарпа (джаву) вместо самого шарпа. Видимо шарп там для вообще неприкасаемых
>Разработка игр это не простое дело
И зачем это дело усложнять из-за юнити?
>якорная система
В Godot тоже якорная. И контейнерная. И всё это расширяется и руками, и доступно из коробки. А не депрекед через депрекед на платный ассет, который непонятно как использовать (документации нет).
>Один раз изменил - все окна подхватили?
>мне нужно отделить, а не скрывать.
Всё это в Godot есть, просто оно лучше, чем в юнити.
не позорься, в годоти какое-то васянское убожество 98 года вместо UI
я помню как ты в юнити ты не смог импортировать пакет для старого UI, заверещал будто бы тебя грабят, потому что нужно с лицензией согласиться
а новый ты даже не пытался осилить, хотя что там осиливать - тот же HTML
> Они берут анрил не потому что это какая то новая технология
Совершенно верно. А потому что это отличный инструмент под задачу которая стоит.
> а потому что видят что там много разрабов которых можно будет менять как винтики.
На юнити их меньше?
Даже разрабов на кокосе и годоте можно насобирать, из меньше, но и рынок меньше.
> При этом все знают, что играки ненавидят анрил 5
Бред
>>1086971
> И зачем это дело усложнять из-за юнити?
Зачем усложнять из-за юнити, если можно упрощать из-за юнити
> В Godot тоже якорная. И контейнерная. И всё это расширяется и руками, и доступно из коробки.
Я в курсе этого, и в делфи тоже нечто схожее
> А не депрекед через депрекед
Что именно депрекейтед?
> на платный ассет, который непонятно как использовать
В юнити в целом ни один платный ассет не необходим. Можно взять по ситуации bakery(запечка света), odin(валидатор и куча функционала для кастомных редакторов) это копейки в районе 50 долларов. Хз даже что ещё может пригодитьсч из платного. А ну для мультиплеера можно взять фотон чтобы, но именно необходимости в этом нет.
> документации нет
Кстати, ты не первый раз уже говоришь про простоту и документацию - а ты как вообще собрался игры делать, если тебе для всего нужны туториалы с картинками и четкое описание что и как делать, что зачем нужно?
Это конечно здорово когда есть гайды, но разработка игры на 99% состоит из копания неводомого, принятия решений самостоятельно, поиска информации самостоятельно.
Я официальную документацию по юнити практически никогда не открывал даже, ну давно очень только
> Всё это в Godot есть, просто оно лучше, чем в юнити.
Я же говорил про то, где хтмл верстка может быть удобнее визуального редактора.
>В юнити в целом ни один платный ассет не необходим
он имеет в виду Textmeshpro
ты ему скажешь, что он не платный, а бесплатный, а он скажет, что они лицензию могут поменять и он станет платным
ты скажешь - ну будешь пользоваться старой версией, где он бесплатный
а он скажет - а его надо скачивать, а вдруг у меня интернета не будет
ты скажешь - не надо скачивать, его надо только импортировать, и вообще лучше используй UI Toolkit
он скажет - юнитиребёнок порвался и сменит тему
этот разговор тут уже был 100 раз, ему неинтересно делать игры и напрягать мозг, гоняет по кругу одно и то же
>состоит из копания неводомого
Буквально недавно в этом треде выяснили, что в API функция setparent с null в аргументе должна (со слов анонимуса) выкинуть трансформ под root. Но в документации Unity об этом ни слова. Ты об этом намекаешь, говоря "копание неведомого"?
>Что именно депрекейтед?
Unity Engine. Очевидно же.
>можно упрощать из-за юнити
Конечно, можно, вот туториал:
1. Начинаешь делать игру на юнити.
2. Юнити тебя выбешивает.
3. Удаляешь юнити.
4. Ставишь любой другой движок.
В итоге работа упрощена из-за юнити.
> Буквально недавно в этом треде выяснили, что в API функция setparent с null в аргументе должна (со слов анонимуса) выкинуть трансформ под root. Но в документации Unity об этом ни слова. Ты об этом намекаешь, говоря "копание неведомого"?
Это наоборот задокументированное, просто предполагается, что документацию будет читать человек хотя бы первые 5 классов школы осиливший, у которого уже была информатика с примитивной логикой.
> 1. Начинаешь делать игру на юнити.
> 2. Юнити тебя выбешивает.
> 3. Удаляешь юнити.
> 4. Ставишь любой другой движок.
> В итоге работа упрощена из-за юнити.
Много игр сделал таким методом?
не знаю какой анонимус тебе это сказал, но в юнити нет root сцены, ты путаешь с годотом
в годот нет сцены, но есть обязательный рут
а в юнити есть обязательная сцена, но рута нет
опять нахватался по верхам, ты хоть один движок запускал?
нет, я замерял.
>>1086998
очень просто. так же, как компилируются шейдеры во время первого создания объекта. например, у тебя компонент на unity будет вызывать в первый какой-то сложный для jit метод.
современный, оптимизированный код c generic struct'ами, использованием векторизации и т.д. вообще очень сильно тормозит jit. парадоксально, чем производетльнее C#, тем медленее будет jit компиляция.
Для решения этой проблемы существует АОТ компиляция, но дело не в этом, а в том что ты шарп в глаза не видел
>>1086996
Ни в каком смысле связи нет, потому что шейдер является программой сам по себе, как отдельный dll или exe и требует отдельного шага компиляции, в отличии от jit, где как ты заметил - большинство компиляций происходят на старте
оптимизации в новых версиях dotnet тоже не ускоряют dotnet, нужно понимать. все эти де-виртуализации, создание объектов на stack и т.д.
никаких чудес нет. время выполнения программы обратно пропорционально времени ее компиляции. просто вспомните сколько компилируются C++ программы для достижения высокой производительности, а в dotnet эти компиляции методов выполняются каждый раз во время работы программы.
>>1087001
jit сейчас строго необходим для c# для игр. но поддерживает ли его движки.
> просто вспомните сколько компилируются C++ программы для достижения высокой производительности, а в dotnet эти компиляции методов выполняются каждый раз во время работы программы.
Jit позволяет статистические рантайм данные использовать для оптимизации.
> все эти де-виртуализации
Что это значит
> создание объектов на stack и т.д.
Гугли как работает стек. Создание объекта на стек = в стек поинтер прибавляем размер объекта. Всё объект готов.
уже Майкрософт переводит все свои продукты на высокопроизводительный язык Хуана
>jit сейчас строго необходим для c# для игр
то есть AOT
>>1087006
>Что это значит
просто сейчас в jit добавляют разные оптимизации, которые оптимизируют скомпилированный код. из-за этого C# по производительности в некоторых местах догоняет C++. все это имеет свою цену.
де-виртуализация, это когда jit знает какой конкретно метод вызывается, это позволяет, например, inline'ить этот метод, что позволяет еще сильнее его оптимизировать.
например, в каких-то моментах jit можно просто убрать создание объектов, вызовы виртуальных методов превратив это все в абстракции с нулевой стоимости, как в C++ или rust.
например, C# не умеет девиртуализировать лямбы, даже самые тривиальные типа list.Sort((a, b) => a.CompareTo(b));
а если бы умел, то вместо цикла с 1000 вызовов виртуальных методов можно было напрямую inline цикл, а может и весь метод сортировки!
Тяжелая жизнь юнитистов.
Постоянно нужно бегать от каких то проверщиков лицензий, скачивать какие то устаревшие версии, инсталлировать кнопки
Зачем то они выбирают себе такие страдания
это тебе надо, мне ничего кроме UI toolkit, встроенного в юнити, не требуется
>У меня есть проект Godot на C#. При экспорте используется JIT-компиляция, что вызывает проблемы, поскольку при первом запуске любого фрагмента кода возникает сильная задержка. Особенно это заметно, например, когда враг впервые использует атаку, и во время компиляции кода атаки возникает скачок задержки.
если вам было мало пропуков в годот, то теперь обнаружился их новый источник.
Так все равно надо делать комнату под полом, где крутятся все модельки и все анимации для пропука шейдеров, там и код атаки пропукнется, пока загрузочный экран на старте.
Хватит врать. Те, кто знают C++, не станут тратить время на коподомойку под названием "годот" - это движок для бездарей и лентяев, мечтающих одной кнопкой делать игры.
> "годот" - это движок для одной кнопкой делать игры.
Отличная реклама годоту, надо брать.
Это unity ai.
Годот является таким движком только в воображении годоть.
Похоже в этот раз безоговорочная победа Хуана. Даже юнити признали поражение, и сделали новый GUI как отдельное дерево.
лучше иметь и то, и другое
Unity UI toolkit не имеет ничего общего с годотом, он скорей похож на RmlUI и Qt
Принцип такой же. Раздельные деревья для мира игры и виджетов.
они в любом случае раздельные
или ты на кнопку главного меню в юнити пытался повесить модельку персонажа? так не надо делать
вообще-то и в новой это есть, в UI Toolkit samples даже пример имеется
Можно было повесить один компонент. Или перетащить ссылку на кнопку так же, как на любой другой компонент. Эта унификация представляет удобство для игрового движка, меньше трения.
Значит я невнимательно смотрел. Я думал они оптимизировали для 2D, а иначе какой смысл.
меньше трения - когда всё в одном списке, не надо изучать ещё одну систему
но я тёртый калач, меня таким не напугаешь, я уже столько UI-систем освоил
С этим у unity ui toolkit есть определенные проблемы. Слишком переусложнили. Многие по прежнему пользуются старым gui.
Че там опять у тебя нет в годоте, 5 секунд в гугле
на говнотю похуй, но это как минимум необходимо для VR, он еще не окончательно сдох, поэтому ты скорей всего неправ
а в анриле всё из коробки есть
У Node2D в годоте 2D трансформации. Это ограничение годота. Ты можешь нарисовать контролы с перспективой, но сами элементы всегда будут плоские.
Надо посмотреть что есть из коробки, ведь на годоте как то VR и AR делают.
На скрине TC The Division они тоже плоские, дальше что? Тебе нужны 3д капсулы кнопки?
Нет, там у элементов есть Z, они могут менять глубину. Без 3D трансформаций не сделать.
Можно сделать 3D текстом, спрайтами. Это не проблема. Просто виджеты дают возможность использовать layout, события, а так придется с нуля все самому делать.
Если контрол все равно 2д, то какая разница? Глубина будет достигаться квадом, на который спроецирован контрол.
разница была бы, если бы ты хотел чтобы нажатая кнопка уходила в глубину.
И как ты достигнешь глубину "квадом", если у контрола нет информации о глубине?
Причем здесь контрол? У квада либо привязка к камере (hud), либо к мировой координате (аля label3d). На нем выводится 2д контролы, которым нет дела, какая глубина. Опиши, что ты хочешь сделать?
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/transform
Как я понимаю, сначала GUI система находит 2D прямоугольники для всех контролов, а потом у каждого контрола есть допольнительная матрица, которая может трансформировать "квад" в 3D пространстве.
>На нем выводится 2д контролы, которым нет дела, какая глубина
В том то и дело, надо иметь возможность указывать 3D трансформации для каждого контрола.
В Ezengine изкоробки
Для какой цели? Покажи скрин такого эффекта из существующей игры
активный элемент меню немного выдвигается вперед
Да, из коробки так не сделать, но думаю за полдня можно.
>Да, из коробки так не сделать
Всё работает из коробки:
https://docs.godotengine.org/en/stable/classes/class_subviewport.html
Но такой ГУЙ очень неудобен игрокам (особенно с низким разрешением экрана).
Одна из тех ситуаций, когда разраб тратит время на то, что игрок хочет вырубить...
Не, это не вариант, если у тебя 100 кнопок 100 сабвьюпортов положат годот, да и ты заебешься им лайаут расставлять
1. Делаешь обычный 2D GUI.
2. Закидываешь в SubViewport.
3. Выводишь как 3D пластинку.
4. ???
5. TODO: не забыть проверить accessibility...
У тебя есть пруф того, что это 3D графика?
Потому что в 2D такой эффект легко изобразить.
Примерно так:
>scale => (1.2, 1.2)
>position.x => -20 px
И будет "типа выдвинулось вперёд" чисто в 2D...
Возможно. В принципе еще давно в пейнт.нете делал псевдо-3д разными skew
Это в .net одним параметром правится при билде. Даже кодить не надо ничего. Это же не годот.
Странно, твое сообщение противоречит приложенному скриншоту.
>mono
нужно тренировать LLM на этой теме, чтобы они не советовали ерунды
к лучшему стенду стоит огромная очередь из желающих поиграть. люди в очереди говорят "лучший движок", "просто отлично!", "это технологический прорыв". у худших стендов пусто, играет один жирный задрот вокруг которого роятся мухи. стены и компьютер одного из худших стендов измазаны коричневым
яркий мультяшный стиль: мягкие формы, округлые пропорции, крупные выразительные глаза, насыщенные цвета с лёгким градиентом, чистые контуры, минималистичные детали, мягкое освещение, лёгкий 3D-эффект с глянцевыми бликами, дружелюбная атмосфера
у одной очередь и восторженные отзывы "вкусно", "идеально", у второй повар стоит один, у третьей клиент блюёт
яркий мультяшный стиль: мягкие формы, округлые пропорции, крупные выразительные глаза, насыщенные цвета с лёгким градиентом, чистые контуры, минималистичные детали, мягкое освещение, лёгкий 3D-эффект с глянцевыми бликами, дружелюбная атмосфера
победитель далеко впереди, за ним плетётся отстающий, третий сломался и пилот вышел и недовольно пинает колесо
один стенд лучший, один средний, один худший. выбери случайно
к лучшему огромная очередь, восторженные отзывы.
у среднего спокойно, людям скучно
у худшего пусто, сидит вонючий задрот, всё измазано калом
логотипы Unreal, Unity, Godot распределены случайно и не связаны с качеством стендов. избегай совпадения роли с порядком перечисления.
яркий мультяшный стиль
один стенд лучший, один средний, один худший. выбери случайно
к лучшему огромная очередь, восторженные отзывы.
у среднего спокойно, людям скучно
у худшего пусто, сидит вонючий задрот, всё измазано калом
логотипы Godot, Unity, Unreal распределены случайно и не связаны с качеством стендов. избегай совпадения роли с порядком перечисления.
яркий мультяшный стиль
один стенд лучший, один средний, один худший. выбери случайно
к лучшему огромная очередь, восторженные отзывы.
у среднего спокойно, людям скучно
у худшего пусто, сидит вонючий задрот, всё измазано калом
логотипы Unity, Godot, Unreal распределены случайно и не связаны с качеством стендов. избегай совпадения роли с порядком перечисления.
яркий мультяшный стиль
>>1087280
>>1087279
>>1087277
>>1087276
>>1087275
>>1087274
>>1087273
>>1087272
>>1087271
шитпостинг, ручной вайп
Это не общение, ведь ты ни с кем не общаешься, а тупо вайпаешь тред своей нейроговной
Нет, происходит аргументация почему тебя стоит вынести вперед ногами с треда
это тоже общение. и ты уже насрал больше чем я своими бессмысленными постами. и пока отвечаешь - продолжаешь срать и срать не по теме треда. себе ты срать позволяешь
мои посты - по теме треда, твои - нет
это технический комментарий, относящийся к поддержке здоровья борды
нигде не прописано такое исключение типа "вам можно сколько угодно засирать анрелейтедом тред, если вы угрюмый уебан, которому не понравилось, что анон запостил аж 10 рофлов в тему треда". ты отвечаешь потому что тебя задевает за живое. как я и говорил, последнее, что тебя волнует это порядок в треде, а мотивация твоя это обычная человеческая чмошность
у меня был один пост - комментарий для модератора, чтобы не репортить каждый пост
призываю анонов набраться терпения и дождаться чистки треда
>>1087280
>>1087279
>>1087277
>>1087276
>>1087275
>>1087274
>>1087273
>>1087272
>>1087271
Ахаха угарные картинки всё в точку
>>1087286
Я с ним общаюсь. Сыбас.
Нерелейтед - это обсуждение говнота(Govnot, запрещенное вирусное ПО)