Комментарии 24
Пост еще одно доказательство того, что делать надо что-то одно. Или игру или изучать новые движки и(или) языки .
поскольку все системы в Bevy открыты для экспериментов и совершенствования, все они потенциально подвержены регрессиям.
Какая элегантная формулировка для "следуя современным тенденциям, мы кладем на эту вашу обратную совместимость"...
О какой обратной совместимости речь, если говорится про 0.х версии движка? И причём тут современные тенденции, если это как раз давняя классика semver?
Это как бы не от версии зависит, а от отношения разработчиков. Я видел много 0.x версий, которые работали мегастабильно и очень хорошо поддерживали обратную совместимость.
Если этого не делать - ну как бы ни один приличный разработчик не будет использовать библиотеку, "спасибо, экспериментируйте дальше, но без меня". Ну, или будет - если будет к этому принужден ввиду того, что это, например, вендор-локед штука, с которой он вынужден иметь дело по работе (крупные вендоры, даже ОпенАИ, простите, с которой я работаю, обожают периодически донакинуть каких-нибудь полей в ответы; или несколько дней назад сломали работавшую DALL-E-2, просто запретив в вызове поле "quality", которое раньше указывалось как стандартное.)
Это какие-то разговоры ни о чём. Эти самые "много 0.x версий, которые работали мегастабильно и очень хорошо поддерживали обратную совместимость", они с нами в одной комнате? Никакой конкретики.
В топике указывается двигло в котором только 1-3 разраба на полноценных донатах от сообщества сидят, все остальные делают это на энтузиазме. При этом сам же приводишь в пример поломку API от корпораций с сотнями разрабом и миллионами юзеров. Очень толсто.
Движку на ранних стадиях развития нужно развивать концепции как можно быстрее и не обременять себя бесполезной поддержкой API, которое считай, мало кому нужно.
Все ждут 1.0, поэтому "ломать и ещё раз ломать" – это единственно верный вариант для них сейчас..
Это какие-то разговоры ни о чём. Эти самые "много 0.x версий, которые работали мегастабильно и очень хорошо поддерживали обратную совместимость",
За игры не подскажу, к сожалению не разбираюсь, но например FastAPI все еще 0.xxx, однако уже два года со мной в проде. Каких-то прямо сильно ломающих изменений, чтобы приходилось тратить много времени не помню
Однако стараемся переписывать все, что стало deprecated
Эти самые "много 0.x версий, которые работали мегастабильно и очень хорошо поддерживали обратную совместимость", они с нами в одной комнате? Никакой конкретики.
Вы, наверное, шутите? Это же "software's most popular versioning scheme". Их "миллион".
https://0ver.org
Все было бы так, если бы не один нюанс. У bevy в документации написано отдельным выделенным блоком, что движок в альфа версии, еще не весь инструментарий готов, и они будут ломать апи в новых версиях.
Те, кто ожидают что спустя полгода-год смогут поменять циферку bevy в зависимостях, и у них все заработает - как минимум наивны.
в юнити тоже проблемы с апи. они до конца не доднлывают старые, пишут новые.
сеть текущая обсолет, новая не готова. новый рендер апи прикрутили, сейчас переделывают избавлясь от hdrp. а в новых версиях юньки, снова пепеделывают в универсальный рендер пейплайн.
ui обсолет, новый аля web. еще не релиз рейди.
аниматор, все жалуются. его не передедывают, пишут новый!
это на вскидку вспомнил.
Вы знаете, я даже у двух чат-ботов спросил, но они не знают. Что это за новый рендер апи, который должен заменить hdrp?
И в Юнити вообще знают об отказе от hdrp? Я об этом так и не смог нагуглить
Может вы имели ввиду, что создали новые рендеринг пайплайны (в т.ч. URP и HDRP) и сделали обсолит старый built-in метод рендеринга?
рендер апи в Юнити это типо конвеер(реализованный в Сшарпе и прокинутый пользователю) гляньте схемку Вулкана что-то +- такое, Вулкан ближе к дирексИкс
там конечно и гл есть отдельно и вулкан и дирекс, ну просто схема Вулкана если найдёте будет +- хотя она спецфичная, на ГЛ апи до нее можно дойти но не тривиально, просто стадии будут как повторная отрисовка
Я так понимаю, что это тот же hdrp, просто было так, что "мы перейдем с обычного рендера на кастомные рендер пайплайн, а потом не нужно ничего делать".
Но при переходе к 2022 и к Unity 6 что-то таки изменилось, часть внутренних API таки изменилась.
У нас поплыли при миграции части, требующие доступа к RT камеры, пришлось переписывать. Справедливости ради, они использовали хаки, так что тут мы сами виноваты, но у других разработчиков могли сломаться и обычные скрипты.
Они соединяют hdrp и ldrp или как там его, просто в urp. т.е. у них были две обособленные ветки со своим подходом, сейчас это универсальный urp. А новый который они пилят, будет помоему в версии 6.2 посмотрите их презентацию на 6 версию. там юнифай чтоли он будет называться.
Краткая выжимка статьи-перевода:
Один из двух "разработчиков" никогда раньше не программировал и не смог освоить rust.
В rust код сложно вносить изменения - они хотели получать runtime error'ы, а вместо этого rust компилятор плюётся ошибками компиляции.
Все AI знают только о предыдущей/пред-предыщей версии bevy, поэтому AI генерируют код, не компилирующийся в последней версии bevy.
Разработчики хотели для своей игры движок, основанный на ECS, но оказалось, что на другом движке, не используя ECS подход, у небольшого игрового проекта будет в разы меньше строк кода.
Для Unity есть реализация astar, а для раста они ее не нашли... https://crates.io/crates/pathfinding
Поддержку модов в rust/bevy впилить будет очень сложно - пожалуй единственное, с чем в полной мере соглашусь.
им нужна быстрая итерация совместной разработки, С шарп этому отвечает как и java, 2 пункт тоже критичен, Юнити/Анриал этому отвечает, представьте если это какой-нить старфилд, там код сурс движок и сурс геймплей, им хочется простоты взаимодействия в разработке
это статья наверно про то как Сеньора заколебала ужимка в угоду хайпа и он понял что так проще просто, моё имхо
моды через люа можно внедрить
Ну то есть правильно перешли, вопрос зачем начали с bevy
Энтузиасты.
Раст во многом не понят, его любят, но он тяжелое дитя.
Он обещает zero cost abstractions, но это только для производительности zero cost, для разработчика это еще как не бесплатно с точки зрения понимания.
Область, в которой проблемы не были решены и которая, скорее всего, будет стоить нам некоторых неудобств — это локализация. В Rust есть проект Fluent, делающий ровно то, что нам нужно. Пока мы не нашли сравнимого решения для Unity.
Кстати, а что есть во Fluent, чего нет во встроенной системы локализации у Unity?
Не могу отделаться от ощущения, что статья - вброс, а сама тема про двух братьев создающих игру - фейк. В оригинале ещё какой-то неуместный Bevy Rap вставлен, для отвода глаз, наверное.
Много чего упомянуто путём притягивания за уши, какие-то левые подробности для достоверности... и как-то стиль отдаёт и нейронкой и методичкой по копирайтингу.
Ссылок на их GitHub не увидел - всё на доверии. Моддинг ему не пошёл - он слепой, сразу не видел как с моддингом? Сама идея миграции с библиотеки на гуйную хрень как ни в чём не бывало - не верю. С какого ему упёрлась стабильность - взял версию Bevy и на ней сделал, так не бывает чтобы на данной версии сделать было нельзя, а на версии на год старше можно. Уж если кто не заставляет обновляться, так Rust. Как можно вообще думать о написании игры и пропустить и/или не заметить, невинно так, Unity?
Цель - либо пиарить Unity, либо опускать Rust (оговорки какие прекрасные, я Rust не опускаю, нет и нет, в нём всё замечательно, только работать нельзя), либо изучать реакцию (которой пока два комента) на собственно вброс, либо самопиар.
Моё мнение может являться как моим так и не моим, как преследовать цели так и отнюдь, при принятии финансовых решений учитываться не должно.
Пытался я написать несколько связанных статьей про Bevy. В итоге перестал, т.к. изменения с каждой версии очень значительные. Описываешь что-то, а для следующей версии это уже не актуально.
На текущий момент мое мнение однозначное - Bevy не подходит для серьезной разработки игр. Надо ждать стабилизации его API и уже только после этого рассматривать его как конкурента зрелым движкам.
Увидел эту статью и вспомнил, что уже читал про то, что не стоит делать игры на Rust.
И действительно. Вот аж в 4 частях.
https://habr.com/ru/articles/811163/
https://habr.com/ru/articles/812661/
https://habr.com/ru/articles/813139/
https://habr.com/ru/articles/813597/
не очень понял пару моментов, которые они сделали, мне кажется, если переносить игру с движка на движок посреди процесса, то стоит уделить больше времени на мониторинг фич, которые предоставляют новые движки
первое: выбор проприетарного Noesis из-за XAML и схожести с WPF, когда в Unity выкатили UI Toolkit, который тоже XAML просто + CSS, конечно, это не продакт-реди, но и Bevy такой же
второе: не знаю, как реализован ECS в Bevy, но было бы странно если при переходе на ООП-стиль кодовая база бы увеличилась. когда нет нужды городить компоненты, системы, сущности, а объединить это в один объект. но ECS ≠ миллион бойлерплейта, я пытался осилить DOTS, но он сильно усложнен, когда я пересел на другой, то и код стал компактнее и понимать его стало проще.
третье: чем встроенный инструментарий локализации Unity хуже Fluent?
Миграция моей игры с Rust