Mikhail Kolobov | Gamedev Forge

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

Немножко мемов, чтобы не скучно было работать в такую погоду

Но вообще настроение устроить стрим с марафоном по ЗВ. Только 6 нормальных частей, а не повесточные фанфики, конечно же

Кто за?🔥

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

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

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

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

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

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

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

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

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

Делаем?)

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

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

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

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

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

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

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

public enum Weapons : MonoBehaviour

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

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

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

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

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

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

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

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

Отдохнули, пора и поработать постримить!

Завтра в 19:00 посмотрим ваши проекты. В первую очередь буду смотреть проекты тех, кто будет на стриме. Остальные - сколько успею. Если останется много и если формат понравится, то устроим еще один

Твоя главная ошибка в создании туториалов! IDisposable в Unity!?

https://youtu.be/bisGKyU1Kyc?si=vSJ7_vJq2mJL3jPQ

Немного не успел и ему, конечно, уже накидали хуев за щеку в комментариях
Но тем не менее:
- не сказано про использование IDisposable в связке с using. Потому что иначе вообще наплевать на IDisposable, можете написать какой угодно свой интерфейс IDestroy/IBeforeDestroy/IDestruct и вызывать его точно также. Аргумент "ну так же типа принято уже" ну совсем слабый)
- раздел "Крутая фишка на основе той же идеи". Где он показывает "смотрите что придумал, а давайте мы напишем наш интерфейс IInitializable чтобы оно тоже круто работало и все инициализировалось одинаково"... Сколько лет зенжекту?)

P.S. у него в программе курса написано что мы "напишем свой DI контейнер". Кто-нибудь был на курсах? Там реально контейнер как у dev jungles или просто сервис локатор, названный DI контейнером, как у "лавки разработчика"?

Никакого unity, просто стримим с женой как играем в Evil Dead

Типичное собеседование на новой работе

Работы много, поэтому пока только мемы)

Для разгона)

Появилась петиция по ликвидации должности HR-менеджеров
Подписываем?)

«Боимся, что ты хочешь получать деньги на работе, не подходишь»

P.S. Найдено на просторах линкедина

Это чье резюме? Признавайтесь!
https://youtu.be/m0kKZMXk0Gs?si=YFxLZ8MGcZzX-xv2