Civilization VII плохому не научит

Никакого контекста, просто ебейшая статья от Юры

Как перестать мыслить монобехами? Гайд для Unity-разработчиков

Здарова пирожочек. Меня тут недавно штангой в качалочке придавило и потянуло написать статью. Да не просто какую то, а что бы было ценно текущим разрабам и подрастающему поколению джуниоров.

У меня проходят на менторство ребята с разным уровнем знаний, но одна из частых ошибок (после неправильного резюме) это большое количество монобехов.

Монобехи повсюду. Если б можно было, то разработчик написал: 

public enum Weapons : MonoBehaviour

К счастью язык C# не позволяет таким способом выстрелить себе в ногу.

В своем большом гайде я разбираю, как перестать думать через призму "А шлепну ка я еще один монобех скрипт" и перейти к подходу, где логика и данные существуют отдельно от Unity, а MonoBehaviour выполняет только роль тонкой связки с движком.

В статье ты найдешь:
 
• Почему MonoBehaviour - всего лишь инструмент, а не архитектура.
• Чем чистые C#-классы лучше для логики: тестируемость, переиспользование, прозрачность.
• Ловушки монобех-мышления и признаки нездоровой архитектуры.
• Как сменить парадигму от «поведения на сцене» к «данным и логике».
• Практические примеры: пошаговый рефакторинг скриптов с разделением логики и MonoBehaviour.
• Советы по организации кода, отказу от статических синглтонов и управлению зависимостями - без сложного DI.
• Итоговый чек-лист для тех, кто хочет постепенно оздоровить проект.

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

Читай гайд на Medium: ссылка на статью

Сохрани себе, чтобы возвращаться к нему по мере развития проекта! А если статья помогла  -  не забудь поделиться с корешами, которые не знают как писать игры на чистом C# без монобехов.

Раз в геймдеве нет ничего подобного, предлагаю такой вариант:

P - Panzar Studio
E - Eon Games
N - Nekki
I - Ice-Pick Lodge
S - Saber Interactive

Делаем?)

P.S. если кто-то не шарит за road to FAANG, то это курс за 500к без гарантии трудоустройства и тоже с накруткой опыта, но про которую стесняются говорить ПОТОМУ ЧТО ЭТО ФУ ПЛОХО

Интересно, есть ли вариант с пост оплатой…

Даже повыделываться негде, вроде все по факту
Хотя как вспомню его определение паттерну "репозиторий", сразу корежит

Еще день, еще схемка! MVVM подъехал

Дисклеймер: схемка расширяет информацию из предыдущего поста

MVP, MVC, MVVM - распространенные архитектурные паттерны в разработке приложений. Многие говорят, что они фигово ложатся на геймдев, и доля правды в этом есть. Нюанс в том, чтобы понять кто такой View, а кто такой ViewModel/Controller/Presenter, кто из них является монобехом и кто кем управляет. Небольшая путанница, я бы сказал.

На мой скромный взгляд, лучше всего на движок ложится MVVM подход, потому что его легко можно раскидывать в виде дерева зависимостей спускаясь от корневых вьюмоделей и баиндеров и глубоко внутрь во вложенность. Очень хорошо ложится на движок, монобехи, префабы и т.д.

В своем опыте я видел несколько реализации MVVM, из них была плохая только одна: где ViewModel была монобехом. Было жутко неудобно и непонятно зачем так. Самая надежная схема (представлена в скриншоте) - когда модель представлена сервисами и обработчиками данных, вьюмодели могут ссылаться на сервисы, чтобы запрашивать данные или их изенение, а вью, которые представлены баиндерами (монобехами), могут получать данные из вьюмодели (которые доступны только на чтение), подписываться на них и посылать сигналы с запросом на изменение данных (читай Инпут). Вот и всё

Область видимости следующая:
- Данные никого не видят, их могут только обрабатывать снаружи
- Обработчики команд (данных) видят данные и могут их обрабатывать, больше ни о ком не знают
- Сервисы знают про обработчики команд, имеют данные для чтения и методы для запуска изменения данных. В теории могут создавать вьюмодели
- ВьюМодели знают про сервисы, поэтому могут туда посылать запросы на изменение данных. Также они знают о данных (через сервисы), и могут их конвертировать в удобный формат. Например: при изменении количества объектов в инвентаре реагировать внутренним дополнительным флагом IsInventoryEmpty, эти данные торчат наружа (публичные) в виде реактивных свойств. Ну и методы инпута есть, которые прилетают из монобехов
- Вью (то есть баиндеры), знают про их вьюмодель. Она передается через специальный метод Bind(). Таким образом вью может подписаться на изменение данных (даже обработанных вьюмоделью), и посылать сигналы через публичные методы (инпут).

Как-то так. Остались вопросы - обязательно задавай в комментах!

Наконец-то базированные комментаторы)

Че, покупаем микрофон?)

Блять, так вот откуда ноги растут...

Вот так и доверяй метаниту
А я то все гадал, хуле мне эту чушь на мок собесах рассказывают)

Не будем ходить вокруг да около...
23 июля, среда, 16:00, марафон по Звездным Войнам

P.S. Хз насколько это затянется, так как буду душнить про каждую пасхалку в фильмах

Классические джуновые вакансии - работать в Пакистане за 100 евро в месяц

Че, вкатуны, в очередь за билетами?)

Что там сегодня по заботе о бренде?😂

Наш ответ Nanite от Unreal Engine😂😂

Спасибо, что не кассир в пятерочке😂

Да придут все кто веруют (сходка в Москве)

Давно я с вами со всеми не виделся (и пиво не пил). Так что предлагаю в среду 30.07 ближе к 19:00 собраться в каком-нибудь баре, поделиться успехами и познакомиться с новыми членами сообщества

Ставьте в чате + ответом на пост, я добавлю вас в отдельную группу и там вместе решим, куда пойдем

https://youtu.be/bqZVCBEbgHU?si=1h5-KWygj2Wx-KJP

Самый кайф - это раздел "В чем плюс такого подхода". Оказалось, реактивность нужна, ЧТОБЫ УДОБНЕЕ ОТПИСЫВАТЬСЯ

Дальнейшее комментировать отказываюсь😂