Привет, меня зовут Александр.
В небольшой геймдев команде я отвечаю примерно за всё, что связано с визуалом и звуком, и ещё частично игровым дизайном. 3D модели, анимация, VFX, SFX, музыка и много чего ещё. Хочется всё уметь, делать быстро и красиво, а в наличии две руки и одна голова. Как со всем этим справиться? Пытаюсь разобраться. Здесь собираю заметки о том, как куб из Blender постепенно превращается в игровой мир и оживает на движке Bevy.
Привет Александр!
Это если не "ад", то "пыточная камера" для 3D художника.
Зато кодерам нравится.
В текущем состоянии мы имеем локацию в виде планеты и базовые механьки.
>Зато кодерам нравится.
Это ложь. Все что больше утилиты для линукса - раст превращается в неудобную и неповоротливую шляпу.
Поиграться - норм, самоутвердиться норм, если не хватило мозгов на хаскель. Но работать точно нет.
Прямо как в Обивион без блендинга анимаций. Там тоже враг прежде чем нанести урон должен был остановится, чтобы началась анимация удара.
Да, блендинг есть, тут не кривовато, а вообще пока этого вопроса не касались.
Сколько времени уже ушло? Какие планы?
Именно эту планету уже около года делаем, хотелось бы быстрее, но пока это как хобби проект, исключительно в свободное время.
В этом году планируем довести до минимально рабочего состояния и протестировать на itch.io
Что? На картинке просто дженерик.
Но главная проблема инфраструктуры Rust, что там долго компилируется и бинарники получаются по 50 МБ Или по 2 ГБ если для разработки
Вы бы хоть подробнее описали что тут на картинке, непонятно это сингл или мульти, на какой платформе игра и тд.
3D-экшон суть такова... условно - мультиплеерный сессионный PvPvE-экшен с элементами сурвайвала. Бывают такие ситуации, когда до конца не знаешь, что делаешь. У нас примерно так, потому что это первый опыт. По платформам - рассматриваем пока стим и мобилки, но это не точно. В общем, я этот тред завёл, чтобы немножко рассказывать о творческих муках и интересных находках, постепенно и непринуждённо всё прояснится.
1. Нашëл симпатичных персов.
2. Взял чистый лист и сделал наброски.
3. По своим наброскам замоделил. (Потом ещё заригал и анимировал в миксамо)
>>1098760
>>1098674
Есть видосик небольшой https://2ch.org/gd/src/1098414/17855156246020056787.mp4
>На картинке просто дженерик.
Какой дженерик, кек. А че дженерики не люди??
Это все сигнатура функции.
Это дженерик-функция, дженерик-метод.
Ну да, есть некоторые проблемы, что для объединения треитов в один надо создавать свой пустой треит и добавять ему зависимости там всякие Copy, Clone, Sync, Send. Но это не так уж и сложно.
У меня у самого плагин для Bevy дженерик от трёх типов.
А с лайфтаймами что, тоже какие-то проблемы?
Так мб взять юнити и 1 промптом нейронкой сделать то же самое?
не, слишком просто)
вообще когда начинали ещё не было таких инструментов типа opencode и собирались именно руками поделать
и потом, в планах было сделать что-то мультиплеерное и кроссплатформенное, и я не знаю насколько юнити такое может потянуть
1. Потому что Rust 🦀
- сам язык: система типов и владения, которая обещает защитить тебя от выстрела в ногу;
- удобные тулы: сборка, управление зависимостями;
- обещает топовую производительность;
- хобби приносит удовольствие, с корпоративными инструментами и на работе поработаешь.
2. Легковесный, не нужно устанавливать громоздкие инструменты, можно пользоваться чем привык
3. Топовая производительность движка с Entity Component System (ECS) и векторизацией доступа к последовательно расположенным сущностям в памяти
4. Интересно понять, как работает движок, при этом не уйти в написание собственного
5. Работает со стандартными форматами, не изобретает очередной кастомный
6. Абсолютно бесплатный и поддерживается сообществом
Конечно, движок при многих своих плюсах имеет и недостатки, т.к. до мажорной версии ещё далеко. Но мы want to believe.
Ниже подборочка самых известных, успешных или многообещающих игр, созданных на Bevy (или использующих его ключевую архитектуру ECS)
https://store.steampowered.com/app/2198150/Tiny_Glade/
https://store.steampowered.com/app/4410710/Fields_of_Aaru/
https://store.steampowered.com/app/2286390/Tunnet/
https://store.steampowered.com/app/2628450/Times_of_Progress/
https://store.steampowered.com/app/2427820/LongStory_2/
https://store.steampowered.com/app/2909010/DEATHTRIP/
https://store.steampowered.com/app/3060580/El_Mono/
https://jarl-game.com/
https://store.steampowered.com/app/2248000/Roids/
https://store.steampowered.com/app/3615720/Exofactory/
>>1099205
Ецс это подход пригодный для больших проектов, но не всегда.
А на маленьких только если сама концепция игры такая, что перыорманс может стать проьлемой и дод подход с параллелизмом сможет улучшить ситуацию.
Еще может быть норм для детерминированного мультиплеера.
Из всего что ты перечислил реальная причина юзать раст одна
> хобби приносит удовольствие, с корпоративными инструментами и на работе поработаешь.
Всё остальное есть и в других языках.
>язык для крутых бородатых мужиков которые пищут блейзинговый 0.1 наносек код
>система типов и владения, которая обещает защитить тебя от выстрела в ногу
этот же суровый мужик прячется от своей криворукости у компилятора под юбкой
>- сам язык: система типов и владения, которая обещает защитить тебя от выстрела в ногу;
Побеждает проблему ручного управления памятью, то есть ту проблему которой не было у C#/lua/js/GDscript... программистов. Действительно.
>- обещает топовую производительность;
Обещать не значит жениться, можно просто подключить библиотеку и слететь на порядок по производительности.
Уметь писать оптимизированный код, это отдельный скилл (10%) и тонна исследование с замерами (90%). Зато раст компилируется ппц как долго и бинарь размером с дом.
>- хобби приносит удовольствие,
Мастурбация тоже, но мы об этом не говорим на каждом углу.
>2. Легковесный, не нужно устанавливать громоздкие инструменты, можно пользоваться чем привык
Чтобы собрать на винде тебе надо поставить 7-8 гигов С++ компоновшика, плюс еще вижлу подтянуть (это отдельный размер).
>3. Топовая производительность движка с Entity Component System (ECS) и векторизацией доступа к последовательно расположенным сущностям в памяти
Было с чем сравнить, или просто берем за веру? ECS это не какая-то технология будущего, это подход к организации данных, который несет свои издержки и не всем ECS с такими издержками нужен (простыми словами неудобно, для такого неудобства должна быть реально необходимость).
>Интересно понять, как работает движок, при этом не уйти в написание собственного
Читать сорцы раста с зоопарком трейтов - та еще радость. Для годот даже натянули упрощенный С++, потому что люди ходят развивать проект, упрощая сопровождение кода, а не мастурбировать свое ЧСВ (опять же ЧСВ для слабеньких, кто не осилил реально академический язык - хаскель)
>Абсолютно бесплатный
В эпоху изобилия языков и инструментов - еще бы он был платный.
Поговорил с пастой нейронки. Тут должна быть вирусная шутка из ютуба, что движков на расте больше чем игр на расте (но мне лень искать).
Не ваша статья спустя три года?
https://loglog.games/blog/leaving-rust-gamedev/
>Entity Component System (ECS)
Не очень понял что конкретно в вашейигре надо ECS-ить. Сейчас там буквально две динамические ентити. Персонаж и бегущий за ним говнодемон. Даже если мобов будет одновременно 10+ все равно из пушки по воробьям. Насколько я понял ECS начинает приносить профит если сущностей начинает становится несколько сотен+.
>RUSTRUSTRUSTRUSTRUSTRUST
>ECSECSECSECSECSECSECSECS
Это что, филиал движкосрача?
Я вот не понял, о чём игра...
Не сказать что я стал больше понимать, ну допустим, walking simulator на Rust.
Дарю вам нарратив - главгерой это местная разумная форма жизни, кроме него есть несколько рас которые отличаются цветом и формой ушей. Он думает что самые страшные его враги это местные аналоги змей и медведей, но потом прилетают люди с Земли с огнеметами и начинается тотальная прожарка всей планеты.
Не так. Суть ECS и Bevy, в частности, что берёшь придумываешь компонент, делаешь системы, которые обрабатывают сущности и получаешь новый функционал. Хочешь отключить — убираешь систему, хочешь ещё чего добавить — накидываешь новый компонент и систему.
Компонент это обычная ООП вещь, а не ECS специфичная. Это простая композиция с временем жзни равной времени жизни владельца. Поклонники ECS говорят, что главное тут - это чтобы все пролазило в кеш проца, тогда это будет быстро работать. И действительно будет. Но сама архитектура мне напоминает скорее процедурное программирование годное для простых однотипных задач.
Примерно как писали код под микроконтроллеры. Программа в бесконечном цикле пробегается по всем кнопкам пдряд, опрашивает, подавляет дребезг и если какая-то нажата по программа делает переход к обработчику. Это окей, когда у тебя примитивная хуйня типа кодового замка или пульта от телефизора и кроме кнопок и дисплея в твоей программе нихуя нет. В ООП кнопка была бы отдельным объектом класса, которая сама бы внутри себя как-то обновлялась, подавляла дребезг и генерила бы Евенты OnButtonPressed и OnButtonReleased. Кнопка бы ничего не знала о том, чем она управляет, а в процедурке конкретная кнопка должна была пойти с делать какую-то конкретную вещь. И вот ЕЦС мне очень напоминает микроконтроллер.
Изначально ECS придумали ехидные противники НАСЛЕДОВАНИЯ из ООП, аргументируя пользу ECS приблизительно так: "в ООП вам приходится делать огнемётчика потомком солдата, а солдата потомком человека, а человека потомком животного; но если потребуется что-то поменять, дерево наследования чрезвычайно трудно перестроить; ECS решает эту фундаментальную проблему, позволяя собирать все необходимые объекты в рантайме из компонентов".
Когда-то я тоже думал "о, прикольно звучит", а теперь понимаю, что создатели ECS не разобрались в ООП и сделали квадратно-колёсый велосипед, решающий проблему, которой в ООП нет - никто не заставляет разработчиков юзать наследование... тем более если программируешь на скриптовом ЯП, допускающем множество трюков с памятью и указателями...
Т.е. ECS - это что-то для кодинга на Ассемблере.
> ECS - это что-то для кодинга на Ассемблере.
ну я говорю код стаил микроконтроллера
Спасибо за нарратив!) возьмём на карандаш. Как делать пламя огнемёта, пока не знаю, в vfx вообще ещё сильно не углублялся
Тааак... знак "%" в теме не отображается, понел.
Должно было выглядеть так - 5% текстур, 95% vertex color
Если по камням/скалам нельзя полазить, то они в мире не нужны, нарисуйте вместо них ямы без коллизий. А мне сдается, что нельзя.
Почему же нельзя? можно по камням и скалам прыгать. На планете есть и водоёмы, можно даже плавать
что? Как можно было придумать такую дичь?
В Bevy спавниш сущность и делаешь observe каких-то EntityEvent. Так Pickable работает, добавляешь обсервер с On<Pointer<X>>, где под X может быть Click, Press, Release, ещё что-то. И функция вызывается. Потом можно определить на какую именно сущность был произведён EntityEvent с помощью метода event_target(). Хочешь, можешь хук на компонент подвязать, чтобы обсервер сам добавлялся.
Если говорить про процедурное программирование, то тут подходит macroquad (Rust) или raylib (C++). Когда у игры одно глобальное состояние и надо просто спрайтики выводить, иногда простые анимации, тогда они подходят очень хорошо. Для кликеров каких-нибудь, платформеров.
А если у тебя сложное ПО типа Blender, надо разные World иметь, каждый World обрабатывается своим SubApp, хочется добавить большое разнообразие компонентов, то ECS и Bevy тут очень хорошо идёт. Кстати, в Bevy изначально идёт отдельный SubApp и World для рендеринга, туда пересылаются все рисуемые вещи.
У нас не процедурный мир, я всё вот этими вот руками собираю. Для художников у беви пока есть только обещания сделать редактор, поэтому большая часть моей работы происходит в блендере, и упаковка сотен объектов в один glb файл вполне себе рабочий пайп. Например, в одном glb все объекты и инстансы камней, деревьев, кустов всяких, в другом glb все статичные коллайдеры этих объектов и т.д. А уже дальше, как там в движке оно спавнится, я мало имею представления, это кодеры прочитают, может другой подход предложат. С World'ами мы пробовали что-то покрутить, skein и другие приблуды, ничего особо не понравилось, зависимости непонятные, то работает - то не работает, проще руками через экспорт. Ну и для некоторых объектов custom properties добавляем.
Кстати, в чём самая то важная штука - glb хранит в себе position, rotaion и scale всех отдельных объектов, поэтому в движок файл glb достаточно просто как scene заспавнить и всё выглядит как задумано. На скриншоте вот все пропсы планеты для примера, так файл видит любой gltf viewer и bevy
Мы о разном говорим. Понятно, что сделать можно что угодно хоть на ЕЦС хоть на ООП хоть на простой процедурке как диды. Мой доеб был сугубо к архитектуре, а не к тому что там якобы что-то нельзя.
Еще тут?
1) Расскажите откуда черпаете информацию? Особенное по работе Blender c Bevy.
2) Насколько это удобнее/не удобнее чем движок со встроенным редактором?
3) Какие еще инструменты/плагины используете?
4) Какие подводные есть, то есть с какими неудобствами раста/блендера/bevy сталкиваетесь?
5) И наоборот что больше всего нравится и вдохновляет?