aks2dio: Unity и геймдев

+595
с 2020

Про GameDev, разработку на Unity и C#, менеджмент, образование, менторство и карьеру в целом.

65 подписчиков
31 подписка

Это было бы очень классно 🤩
Добавляю статьи заочно в "вишлист" 📝

Если шутки в сторону оставить, то конечно не имеет смысла переусердствовать там, где этого не нужно.

Всё же зависит от эффективности и масштаба. По мере роста продуктов времени на ручное оперирование уходит всё больше, как и усложняются сами процессы, что повышает шанс на ошибку.

Какой-то момент станет переломным, когда настройка инфраструктуры под CI/CD становится необходимостью для дальнейшего "выживания".

Когда без этой инфраструктуры эффективность не страдает, то и тратить на это усилия будет нецелесообразным.

2
1

На слове "ручной" где-то сморщился DevOps-инженер 😅

1

Ну единица измерения активности радионуклида же 🫠

1
1

Вообще мне сложно его защищать :)
В практике я уже долгое время обхожусь без этого всего.
Прям вот каких-то кейсов, что оно нужно — у меня нет.

Я видел много примеров неудачного применения. И я скорее больше сторонник того, чтобы этим лишний раз не пользоваться.

Но я и встречал коллег, которые умели очень аккуратно и элегантно его встраивать. Ничего кроме этой элегантности, по сути, оно не привносило. Но если ставить целью "упростить оформление" — такими средствами это достигается. И чтобы такое делать — требуется "набивать шишки" и накапливать удачные сценарии применения.

В посте эти условия обозначены — необходимость работы с данными именно как с потоками и потребность в их фильтрации и нетривиальной обработке.

Конкретные примеры привести сложно, т.к. у всех "болевой порог" разный.

Rx не является незаменимым инструментом, без которого невозможно жить. Это вспомогательный инструмент. Он не поможет решить что-то, что без него почему-то не решается. Он лишь поможет в каких-то ситуациях оформить решение элегантнее, понятнее, проще, короче, удобнее и т.д. Или наоборот усугубит.

Поэтому в первую очередь его полезность и применимость познаётся в сравнении. Если где-то профита получилось больше, чем неудобств — вот и кейс в копилку.

Попробую всё-таки в пример. Если вдруг начинает появляться какой-то слишком сложный обработчик, который внутри имеет кучи всяческих условий или пытается заиметь какое-то более глобальное состояние, и это не косяк проектирования, то в таком случае Rx вероятно бы смог помочь оформить это чуть удобнее.

1

Там, где нужны просто евенты, "простые советские" евенты подходят лучше всего 💯

2

Достаточно будет их разобрать и куда-нибудь записать 📝
По мере встречи их воплощения в практике вспоминать, как это называется, и тогда оно само собой запомнится 🧠
Или попасть в душный коллектив, где для отстаивания своей позиции придётся оперировать конкретными понятиями 🤓

Твины используются не только в UI. Какую-нибудь скелетную анимацию через твины делать — смерть, а так для простой одно-спрайтовой аркады можно все анимации реализовать.

И сам Ease — это некоторое правило, как нужно интерполировать значение. Интерполяция может использоваться не только в контексте анимации. Это широко используемый инструмент, который может найти применение в любой области игры.

Да, в UI Toolkit'е есть свой твиннер. И технология весьма перспективная, но пока, увы, не production-ready.

Его сейчас уже удобно использовать при создании интерфейсов для редактора, но потребности игровых приложений он пока не в состоянии покрыть. Поэтому UGUI со скриптами на каждый визуальный чих — всё ещё живее живых.

Ну и некоторые твиннеры тоже предоставляют NoCode решения. Те же LitMotion и DOTween Pro тоже можно использовать, не написав ни одной строчки кода.

Для решений, у которых нет таких возможностей "из коробки", подобные обёртки пишутся за один запрос в GPT и пару минут на перенос. "Проблема" очень просто решается.

Но сложные комбинации из твинов при такой настройке может быть тяжело поддерживать и редактировать. Через VCS контроль изменений тоже постепенно сходит на "нет" по мере усложнения. Т.к. в сериализованном виде такие вещи очень громоздко выглядят. В то время как хорошо написанный программный твин этих недостатков будет лишён.

Поэтому дизайнер, конечно, отдаст предпочтение визуальному редактору. Но если твины делает программист, то ему намного удобнее реализовать всё программно, а для внешнего редактирования вывести только цифры.

Да, отличный пакет 🔥

Мне ещё очень нравится та простота, с которой можно выносить настройки твинов в инспектор.

Правда в плане секвенций тот же LitMotion предлагает идентичный опыт. Другие решения могут уступать в удобстве, но функционально — это достаточно базовая фича для большинства актуальных твиннеров 👀

Все слова DOTween пролинкованы и ведут на офицальный сайт, где есть вся информация.

Что доступно в платной версии из важного — указано.

Пост не про DOTween, по нему и так уже имеется невероятное кол-во контента, а про альтернативные решения. Они все open-source и распространяются бесплатно

1

Так делать очень полезно — помогает глубже разобраться в вопросе и лучше оценивать имеющиеся на рынке решения 👍

Да и кто знает — может этот велосипед однажды поедет в OpenSource и будет с удовольствием рулиться другими разработчиками 😊

1

Да, половину — на C#, половину – на движке, верно 🙂

Unity написан на C++. Всё API Unity –это обращение к C++ либам.
C# – лишь инструмент для пользователя, как и UnityScript в давние времена, когда кроме Mono для Runtime ничего больше не имелось.

🎶 Город-сказка, город-мечта
Попадая в его сети, пропадаешь навсегда 🎶

1

Ну первое, игры "на движке" не пишутся. И второе, код непосредственно Unity – это C++ 🫠
Гол в свои же ворота, получается

Ну, "дома" каждый извращается как хочет. Для меня геймдев, в первую очередь, – это профессия. Поэтому популярность языка я оцениваю его востребованностью.

Востребованность замеряется очень просто — достаточно походить по сайтам игровых компаний и открывать там вкладку с вакансиями.

Обычно там либо Unity, либо UE, либо C++ для самописного решения. И чем компания крупнее, чем проекты масштабнее, тем сильнее выборка клонится в сторону последнего.

С++ всегда считался высокоуровневым языком. Со временем и новыми стандартами он и вовсе абстракциями зарос.
Возможность более низкоуровневой работы не снимает с него этой регалии.

В том же шарпе тоже есть unsafe-код, который позволяет работать с памятью и указателями. Но C# – определённо не низкоуровневый.

В Unigine? Судя по всему - нет. Выдержка с https://internship.unigine.com/ :
"Стажировка предусматривает твое нахождение в офисе в течение 20 рабочих часов в неделю. Мы оборудовали для тебя рабочее место с хорошим железом."

1

По ссылке из поста есть эта информация:
https://internship.unigine.com/

Увы, знаю не больше того, что там написано 🙂

туц.
Оправдать такой большой процент C# достаточно просто тем фактом, что большинство русскоязычных игровых разработчиков – это мобилки и веб на Unity.
Но тем не менее, даже так, топ 2 – это C++.
Так что про "на чём угодно" – очень спорно

туц.
Один только Unreal Engine сколько от рынка отъедает. А это плюсы.
Всякие CryEngine, Frostbite и иже с ними – это плюсы.
Большинство самопальных in-house движков – это плюсы.

Блин, а я ведь тоже догадывался, что все эти крупные игровые проекты свои плюсы только ради челленджа используют — вот ведь бездельники, лишь бы всё усложнить

Удобство и перформанс на разных стульях зиждются. Высоконагруженные проекты, увы, только на C++.

Если настолько в крайности уходить, то выходит, что лучше всего делать на GPT. Но мы же на GPT не пишем почему-то. Почему же? 🤔