Архитектура проекта в Unity. Часть 1

[@eugene8863]

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

[@tigerjustice]

Это невероятно полезная тема. Большое спасибо Вам за эту серию уроков

[@gydrazine]

Как не хватает такого материала на ютубе.) Однозначная подписка с колокольчиком. Только не останавливайся!

[@gamedevlavka]

Сейчас небольшой перерыв, занимаюсь переездом, но скоро вернусь)

[@AndrewDreamKeeper]

Поддерживаю твои слова! ) Честно, я даже не догадывался о таком способе. Меня это заставило переосмыслить свой код..

[@tovkats]

Бро, ты - КРАСАВА!!!!!!!!! Спасибо за ролик!

[@HelloWorld-ln5cy]

Твой канал прямо находка, спасибо за видео, годнота.

[@josephlevy3348]

Это просто сокровище какое-то

[@bombilovka16gd17]

Ух, это было мощно!) Продолжай в том же духе, у тебя все круто получается!!!

[@Jourdfdf]

Перерыла весь ютюб в поиске это инфы, спасибо!

[@supeskok8224]

После прохождения junior pathway на unity learn не мог найти хорошие уроки, это то что мне нужно, спасибо за крутой обучающий контент!)

[@bagi_bk]

Очень хорошая подача материала!!! Спасибо!!!

[@artemvah2210]

Очень интересно! Спасибо за урок!

[@mihailpmv1569]

Было очень интересно) Жду следующего видео!

[@usAnArkx]

Спасибо за видео

[@Fenix72rus]

Обожаю этот канал

[@homelessandhungry4529]

Отличные и полезные уроки!👍

[@vladisslavss]

Хороший урок. Было бы круто если бы вы объяснили про абстракции и назначение абстракций объектам. Но и так не плохо!) Добра вам)

[@aema02004]

Ты крутой. Продолжай

[@ИванРодионов-е4е]

Добрый день! Такой вопрос, вы оставили свойство Coins с публичным сеттером, правильно ли это? Мы же сможем изменить его из любого класса или я что то не понял...

[@MikhailKolobovGamedevForge]

"Репозиторий - это просто название, которое так уж сложилось в жизни что данные будут храниться в репозитории..." Репозиторий - это вполне конкретный паттерн, который абстрагирует хранение данных от предметной логики. То есть предоставляет необходимый интерфейс для приложения с необходимыми ему методами (например: выбрать по id, выбрать все по какому-то признаку, удалить и тд), но само хранение данных делает деталью реализации. Таким образом предметной области становится без разницы, где лежат данные (в scriptable object, в json на устройстве или на сервере) и как они обрабатываются.

[@sequerience]

читая комментарии, посмотрев, какие слова люди употребляют в своих рассуждениях, внезапно почувствовал себя деревенским дурачком

[@yuriimokryi3935]

Очень полезно!

[@РсК-о6ч]

оч полезно. Крутотень

[@great8814]

Привет! После просмотра второго видео заметил сущность Bank и там статика. Зачем она нужна? Если можно просто в тестере обращаться что-то типо такого: _bankInteractor.AddCoins(10); Просто смысла в этой статике не вижу

[@sigvist6228]

А можно где-то найти мануалы или книги про то как нужно проектировать в Юнити или в других игровых движках?

[@dehaproject]

Спустя 2 года спрошу, как успехи?

[@qweerval]

Для меня произошла какая-то магия почему данные сохранились при повторном старте игры? где именно это прописано?

[@shyxiaolong]

А можно ссылку на урок про который вы говорили про ивенты? не нашел у вас на канале

[@kellerkey]

Актуально ещё?

[@DeadRabbitCanDance]

Хорошие у тебя лекции! Подскажи пожалуйста, а есть у тебя что то по архитектуре сетевого взаимодействия? Организация обновления мира, состояний и т.д. Как организовать клиент-серверную архитектуру правильно, чтобы важные вычисления, влияющие на основной геймплей (например попадания) считались на сервере, а клиент занимался только отрисовкой красот?

[@Malryni]

Доброго времени суток, вопрос по архитектуре. Разве должен bankInteractor знать кто его юзает? Его функция ведь в добавлении монеток, а знание кто его юзает - ему не нужно. Или создание некого "GameController" который раскидает по евентам функцию добавления монеток по кол-ву, и затем при условном подборе мы просто заколим евент на подобранную сумму - это плохо? Если да - то чем?

[@_Otets_]

В общем чем-то напоминает UI - BLL -DAL структуру из бизнес приложений.

[@developerazcom]

Спасибо за видео. очень интересно. Хочу спросить один вопрос, такой уровень навыка программирование в рабочей сфере(например в компаниях) должен быть у каждого джуниора или это уже навыки мидла?

[@gamedevlavka]

Это уже навыки мидла. Если джуниор умеет в архитектуру, то это скорее всего уже не джуниор)

[@developerazcom]

@@gamedevlavka понятно, спасибо

[@goga19980]

@@gamedevlavka Раз тут вопрос про джуна) Что на практике нужно уметь джуну по юньке - чтобы устроиться на работу?) Я просто проект для портфолио делаю (полностью свой, а не по гайдам или тип того), парочка механик уже сделана (строительство, взаимодействие с интерфейсем, отправка советников в регионы и доставка в регионы к ним приказов (генерация курьера), управление камерой (2d), экономика базовая).

[@gamedevlavka]

Смотря в какой геймдев рвешься. Больше требуются в мобильный. - Опыт любых проектов приветствуется. Коммерческий проект в приоритете - все платформы - Знание и понимание ООП, более менее красивый и читабельный код - все платформы - Любой опыт запуска проекта в стор (Google Play, App Store) - мобильные платформы - Умение использовать плагины (настраивать внутреигровые покупки, рекламу, аналитику) - все платформы, кроме монетизации. - Умение собирать билды для GP и/или AppStore - мобильные платформы. С таким набором можно куда-то приткнуться, но честно скажу, чем лучше код (четкое понимание ООП, использование паттернов в правильных местах, красивый и читаемый код), тем больше шансов. Даже если остальное недотягивает. Ибо остальное подучить - дело быстрое, а обучить программированию дольше.

[@goga19980]

@@gamedevlavka если дам доступ посмотреть на гитхабе проект, дашь оценку?)))

[@AcidFloor90]

Ну в общем классика - MVC (Model, View, Controller) Только что называется иначе

[@mixer9524]

А каким образом в репозитории сохраняется информация после завершения программы?

[@newgrafon]

загугли что такое PlayerPrefs в юнити

[@quieteroks]

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

[@Nikolai2033]

Почему ты сделал абстрактные классы, а не интерфейсы?

[@gamedevlavka]

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

[@domingo2407]

Ты когда то писал приложения для android? Репозиторий популярный шаблон там)

[@qwerty6vov]

хороший урок и диктор, спасибо! Не подскажешь, твой подход имеет что-то общее с подходами MVVM или MVP или еще чем-то, или он совсем уникальный? Хочется понять немного близко ли это к стандартизированным подходам? Насколько такой подход востребован в студиях? Заранее спасибо!

[@gamedevlavka]

Есть общее с MVC, где View - это UI, controller это интерактор, в Model - это репозиторий. Так как я выводил эту архитектуру самостоятельно, то сходства весьма слабые, но очевидные. Сейчас перепиливаю архитектуру с нуля, делаю все гораздо лучше :)

[@qwerty6vov]

@@gamedevlavka спасибо) надеемся тоже расскажете потом в видео новые версии, очень интересно было бы)

[@user-xl2tf4gq1g]

@@gamedevlavka я не гейм-дев, но с Android. То, что ты показал, относится к Clean Architecture. Клин - не замена MVC/MVP/MVVM/MVI. Клин - общий. В клине есть место для презентационного слоя, куда входят MV* типы архитектур. И одно не понял с передачей sender в interactor: зачем интерактору знать про какие-то эффекты? Не должно ли это находиться в презентационном слое?

[@ЭдуардКик]

Спс

[@theoctan8569]

По сути очень напоминает MVC структуру. По сути репозиторий, это модель(Model). Interactor это контроллер(Controller), а вся остальная игровая логика, это представление(View).

[@gamedevlavka]

Согласен, напоминает. Но я бы не стал проводить аналогию между View и геймплеем

[@Sv9zlsT]

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

[@theoctan8569]

@@Sv9zlsT я бы в качестве представления (view) предложил бы интерфейс, так как, по сути, это и есть представление игровых данных, то есть модели, которой управляет геймплей в качестве контроллера. Как вам такой вариант?

[@paimonc8593]

что за ide?

[@gamedevlavka]

Rider

[@КонстантинПостукян]

Интересно, но вот this глаз режет. Почему бы не соблюдать нотацию и начинать приватные поля с _ ? Райдер ведь подсказывает что this нужен был только в конструкторе. С _ решили бы проблему с this.

[@gamedevlavka]

Вот здесь, я писал, почему я пишу this везде: t.me/gamedevlavka/15

[@Какиграть-д6ю]

Да, я тоже удивился. Потому что привык к нижнему подчёркиванию.

[@nickicool]

тоже пишу с this.

[@aleksalex1479]

Спасибо за видео! Только есть вопрос: это ECS ? И если нет, то можно ли сочетать эту архитектуру и ECS?

[@МихаилСуворов-к2щ]

Это однозначно не ECS. У ECS дргуие слои. E это Entity (Сущьность), C - Component (Компонет), S - System (Система). Они тоже взаимоимодействуют друг с другом. Но по особому

[@uralfansoft]

В других курсах интеракторы называют сервисами, а репозиторий - ассет провайдером

[@dmitriybelousov7246]

День добрый ! Интересно с вами пообщаться на тему совместной работы над проектом...

[@gamedevlavka]

Приветствую! По таким вопросам удобнее общаться в телеграм: @vavilichev

[@Sv9zlsT]

Надеюсь список сущностей архитектуры будет собираться через рефлексию? Не зря же им как метка был сделан базовый абстрактный класс..., Хотя и через интерфейс можно было)

[@gamedevlavka]

Не через рефлексию, через конфиги.. при помощи конфигов, можно делать наборы интеракторов и репозиториев для каждой сцены отдельно)

[@star_killer121]

Зачем ты используешь this при обращении к полям класса? Методы и переменные находятся в единой зоне видимости в классе

[@ilgiz2616]

Автор похоже не из шарпа пришел в программироdание - стиль кода что то на JS похоже ))) Особенно скобки на одной строке и публичные поля с маленькой буквы )

[@vlader776]

Скорее, в компании, в которой он работает такой КодСтайл

[@DarkW1zard]

Мужик в сером на фоне красного ковра :)

[@AmbassadorOfLogic]

Правильно ли я понимаю, что файл "репозиторий" - по сути - база данных?

[@gamedevlavka]

Скорее контейнер с данными. Их можно передавать и забирать откуда-то.

[@Tornado-ln7fq]

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

[@vlader776]

Все в разработке строится на ООП. Каждый игровой объект описывается в классе, в котором прописываешь основную логику этого объекта. Грубо говоря, есть войн у которого есть health, damage, он может принимать дамаг и умирать. А есть игрок, который тот же войн, только управляется через userInput и есть враг, который управляется с помощью ии. Зачем делать дубляж кода для Врага и Игрока, если можно создать абстракцию (шаблон), которым ты опишешь общую логику двух объектов, а потом дополнишь в другом классе их особенности. Но ужаснее всего описывать логику врага и игрока в рамках одного класса..

[@Tornado-ln7fq]

@@vlader776 Вот я про это и говорю.

[@GameStormable]

Так это же обычный MVC, нет?

[@zeverz9621]

Не совсем понимаю зачем нам сущность дробить на интерактор и репозиторий. Не проще ли реализовать сущность с помощью интерфейсов (интерактор и репозиторий) и мы также сможем всем этим управлять, только уже через интерфейсы и не надо будет дублировать инициализацию.

[@ProCLickM]

ПОдписка)

[@hardlandingtac]

Зачем вы придумываете всякие глупости? Архитектура должна помогать разработке, а не её запутывать. Вначале надо ставить цель - какие преимущества вы хотите получить, не нарушив ООП, а уже в рамках этого писать свой код.

[@oneprogofficial]

Зачем столько лишних this?

[@ArtsevDmitry]

Мне эта архитектура не понравилась, создание репозитория в MonoBehavior это зашквар. А где DI контейнер? А как же тесты потом гнать если всё во вьюхах? А почему mediator не применить для развязки? А почему Command и транзакционную обработку не применить, для модификации моделей? ... ??? не буду продолжать ??? ...

[@morons9156]

Данная информация всё ещё актуальна и полезна начинающим разработчикам (коим являюсь я)? Такой же вопрос к плейлисту "Устарело. На пересъёмку". Я начал смотреть, для новичка выглядит очень полезно, но название "устаревшее" немного смущает.

[@chernos]

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

[@chernos]

Сейчас видеоблогер снимает серию видео по созданию игры, рекоммендую к просмотру.