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

No video

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

Рет қаралды 36,573

Күн бұрын

Поддержи канал, бро!
paypal.me/game... - мир
boosty.to/game... - рф
И даже криптой (пока только Ethereum):
0x7a53325D1C36Eea7BbE8C6a8D00f2a0efd580e77
Первый урок из цикла Архитектура проекта. Один из множества способов организации способов, чтобы везде был порядок, и одновременно, мы могли из разных мест получать ссылки на разные механики, места, скрипты. Архитектура кода - важнейшая составляющая разработки больших и средних проектов. Не претендую на использование исключительно моего варианта, но полезных практик и мыслей встретится достаточно!
----------
Поковыряться в моей архитектуре можно скачав проект с GitHub:
github.com/vav...
----------
Архитектура. Часть 2: • Архитектура проекта в ...
Архитектура. Часть 3: • Архитектура проекта в ...
Архитектура. Часть 4: • Архитектура проекта в ...
Архитектура. Часть 5: • Архитектура проекта в ...
___
Лавка Разработчика в других соц. сетях, добавляйтесь!
gamedev... - вконтактик
t.me/gamedevlavka - телеграм канал Лавки Разработчика
t.me/gamedevta... - ламповый чат
/ discord - дискорд сервер

Пікірлер: 92

@eugene8863 3 жыл бұрын

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

@tigerjustice Ай бұрын

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

@Jourdfdf 2 ай бұрын

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

@HelloWorld-ln5cy 3 жыл бұрын

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

@KirillBreuss 3 жыл бұрын

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

@gamedevlavka 3 жыл бұрын

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

@AndrewDreamKeeper 2 жыл бұрын

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

@josephlevy3348 3 жыл бұрын

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

@supeskok8224 3 жыл бұрын

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

@bombilovka16gd17 Жыл бұрын

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

@Fenix72rus 3 жыл бұрын

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

@sequerience Жыл бұрын

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

@vladisslavss 2 жыл бұрын

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

@bagi_bk 3 жыл бұрын

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

@artemvah2210 2 жыл бұрын

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

@MikhailKolobovGamedevForge 2 жыл бұрын

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

@homelessandhungry4529 Жыл бұрын

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

@mihailpmv1569 3 жыл бұрын

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

@aema02004 3 жыл бұрын

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

@DeadRabbitCanDance Ай бұрын

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

@yuriimokryi3935 2 жыл бұрын

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

@user-io6tp1ob3p 3 жыл бұрын

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

@user-eh4fm7ux5z 3 ай бұрын

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

@great8814 2 жыл бұрын

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

@qwerty6vov 2 жыл бұрын

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

@gamedevlavka 2 жыл бұрын

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

@qwerty6vov 2 жыл бұрын

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

@user-xl2tf4gq1g 2 жыл бұрын

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

@theoctan8569 3 жыл бұрын

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

@gamedevlavka 3 жыл бұрын

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

@Sv9zlsT 3 жыл бұрын

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

@theoctan8569 3 жыл бұрын

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

@developerazcom 3 жыл бұрын

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

@gamedevlavka 3 жыл бұрын

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

@developerazcom 3 жыл бұрын

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

@goga19980 3 жыл бұрын

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

@gamedevlavka 3 жыл бұрын

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

@goga19980 3 жыл бұрын

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

@_Otets_ Жыл бұрын

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

@user-hq2wg8pg1l 2 жыл бұрын

Спс

@AcidFloor90 2 жыл бұрын

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

@sigvist6228 3 жыл бұрын

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

@dehaproject 9 ай бұрын

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

@uralfansoft 2 жыл бұрын

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

@quieteroks Жыл бұрын

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

@aleksalex1479 2 жыл бұрын

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

@user-cx1vt1kp1j 2 жыл бұрын

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

@ilgiz2616 2 жыл бұрын

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

@vlader776 Жыл бұрын

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

@Sv9zlsT 3 жыл бұрын

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

@gamedevlavka 3 жыл бұрын

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

@qweerval Жыл бұрын

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

@DarkW1zard 2 жыл бұрын

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

@Malryni Жыл бұрын

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

@domingo2407 2 жыл бұрын

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

@shyxiaolong 2 жыл бұрын

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

@user-pq9pv5vd3m 3 жыл бұрын

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

@gamedevlavka 3 жыл бұрын

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

@user-pc1bs1xy2q 3 жыл бұрын

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

@nickicool 2 жыл бұрын

тоже пишу с this.

@star_killer121 Жыл бұрын

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

@zeverz9621 8 ай бұрын

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

@Nikolai2033 3 жыл бұрын

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

@gamedevlavka 3 жыл бұрын

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

@dmitriybelousov7246 2 жыл бұрын

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

@gamedevlavka 2 жыл бұрын

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

@Tornado-ln7fq Жыл бұрын

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

@vlader776 Жыл бұрын

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

@Tornado-ln7fq Жыл бұрын

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

@paimonc8593 9 ай бұрын

что за ide?

@gamedevlavka 9 ай бұрын

Rider

@GameStormable Жыл бұрын

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

@mixer9524 Жыл бұрын

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

@newgrafon5185 Жыл бұрын

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

@AmbassadorOfLogic 2 жыл бұрын

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

@gamedevlavka 2 жыл бұрын

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

@ProCLickM Жыл бұрын

ПОдписка)

@hardlandingtac 2 жыл бұрын

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

@proggerpro4 6 ай бұрын

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

@ArtsevDmitry Жыл бұрын

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

@morons9156 2 ай бұрын

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

@chernos 2 ай бұрын

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

@chernos 2 ай бұрын

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