Спасибо, недавно начал изучать юнити с целью саморазвития в геймдеве и столкнулся с проблемой, что мало инфы про архитектуру и структуру проектов. Очень хотел бы увидеть архитектуру на каком то простом, но правильном продакшен примере, дабы не изобретать свой велосипед и не гавнокодить. Буду ждать следующие части, не забрасывай.
Добрый день! Такой вопрос, вы оставили свойство Coins с публичным сеттером, правильно ли это? Мы же сможем изменить его из любого класса или я что то не понял...
"Репозиторий - это просто название, которое так уж сложилось в жизни что данные будут храниться в репозитории..." Репозиторий - это вполне конкретный паттерн, который абстрагирует хранение данных от предметной логики. То есть предоставляет необходимый интерфейс для приложения с необходимыми ему методами (например: выбрать по id, выбрать все по какому-то признаку, удалить и тд), но само хранение данных делает деталью реализации. Таким образом предметной области становится без разницы, где лежат данные (в scriptable object, в json на устройстве или на сервере) и как они обрабатываются.
Привет! После просмотра второго видео заметил сущность Bank и там статика. Зачем она нужна? Если можно просто в тестере обращаться что-то типо такого: _bankInteractor.AddCoins(10); Просто смысла в этой статике не вижу
Хорошие у тебя лекции! Подскажи пожалуйста, а есть у тебя что то по архитектуре сетевого взаимодействия? Организация обновления мира, состояний и т.д. Как организовать клиент-серверную архитектуру правильно, чтобы важные вычисления, влияющие на основной геймплей (например попадания) считались на сервере, а клиент занимался только отрисовкой красот?
Спасибо за видео. очень интересно. Хочу спросить один вопрос, такой уровень навыка программирование в рабочей сфере(например в компаниях) должен быть у каждого джуниора или это уже навыки мидла?
@@gamedevlavka Раз тут вопрос про джуна) Что на практике нужно уметь джуну по юньке - чтобы устроиться на работу?) Я просто проект для портфолио делаю (полностью свой, а не по гайдам или тип того), парочка механик уже сделана (строительство, взаимодействие с интерфейсем, отправка советников в регионы и доставка в регионы к ним приказов (генерация курьера), управление камерой (2d), экономика базовая).
Смотря в какой геймдев рвешься. Больше требуются в мобильный. - Опыт любых проектов приветствуется. Коммерческий проект в приоритете - все платформы - Знание и понимание ООП, более менее красивый и читабельный код - все платформы - Любой опыт запуска проекта в стор (Google Play, App Store) - мобильные платформы - Умение использовать плагины (настраивать внутреигровые покупки, рекламу, аналитику) - все платформы, кроме монетизации. - Умение собирать билды для GP и/или AppStore - мобильные платформы. С таким набором можно куда-то приткнуться, но честно скажу, чем лучше код (четкое понимание ООП, использование паттернов в правильных местах, красивый и читаемый код), тем больше шансов. Даже если остальное недотягивает. Ибо остальное подучить - дело быстрое, а обучить программированию дольше.
хороший урок и диктор, спасибо! Не подскажешь, твой подход имеет что-то общее с подходами MVVM или MVP или еще чем-то, или он совсем уникальный? Хочется понять немного близко ли это к стандартизированным подходам? Насколько такой подход востребован в студиях? Заранее спасибо!
Есть общее с MVC, где View - это UI, controller это интерактор, в Model - это репозиторий. Так как я выводил эту архитектуру самостоятельно, то сходства весьма слабые, но очевидные. Сейчас перепиливаю архитектуру с нуля, делаю все гораздо лучше :)
@@gamedevlavka я не гейм-дев, но с Android. То, что ты показал, относится к Clean Architecture. Клин - не замена MVC/MVP/MVVM/MVI. Клин - общий. В клине есть место для презентационного слоя, куда входят MV* типы архитектур. И одно не понял с передачей sender в interactor: зачем интерактору знать про какие-то эффекты? Не должно ли это находиться в презентационном слое?
Доброго времени суток, вопрос по архитектуре. Разве должен bankInteractor знать кто его юзает? Его функция ведь в добавлении монеток, а знание кто его юзает - ему не нужно. Или создание некого "GameController" который раскидает по евентам функцию добавления монеток по кол-ву, и затем при условном подборе мы просто заколим евент на подобранную сумму - это плохо? Если да - то чем?
В конце прозвучала плохая фраза "отделять данные от их обработки". Это один из вариантов, но он приносит к сожалению много боли и дублирования кода. Ну а репозиторий желательно должен предоставлять доступ к сущности, а не к данным.
В ассете, ссылка на который есть в описании я сделал интерфейсы и абстрактные классы. В видео же я показываю идею, поэтому многие моменты сокращаю, и так как мне все равно нужно было реализовать некоторое поведение по-умолчанию, то для видео не стал писать интерфейсы. Но да, по-хорошему, лучше их использовать
Это однозначно не ECS. У ECS дргуие слои. E это Entity (Сущьность), C - Component (Компонет), S - System (Система). Они тоже взаимоимодействуют друг с другом. Но по особому
По сути очень напоминает MVC структуру. По сути репозиторий, это модель(Model). Interactor это контроллер(Controller), а вся остальная игровая логика, это представление(View).
Да на первый взгляд как mvc но если присмотреться то Вью нету по сути интерактор и репозиторий выполняют роль модели, геймплей возможно как контроллер а Вью просто нету)
@@Sv9zlsT я бы в качестве представления (view) предложил бы интерфейс, так как, по сути, это и есть представление игровых данных, то есть модели, которой управляет геймплей в качестве контроллера. Как вам такой вариант?
Интересно, но вот this глаз режет. Почему бы не соблюдать нотацию и начинать приватные поля с _ ? Райдер ведь подсказывает что this нужен был только в конструкторе. С _ решили бы проблему с this.
Надеюсь список сущностей архитектуры будет собираться через рефлексию? Не зря же им как метка был сделан базовый абстрактный класс..., Хотя и через интерфейс можно было)
Я дико извиняюсь,я просто хочу спросить,а обязательно писать ооп,вить когда мы прибегаем к ооп,мы подразумеваем,что мы сделаем некие инструменты,для наших целей,чтоб в итоге что то строить с помощью их.Ну если нам нужен функционал,мне кажется применять ооп подход крайне расточительно,почему я так говорю,если в дальнейшем мы не будем пользоваться этим инструментом,то такой подход просто теряет смысл ?
Все в разработке строится на ООП. Каждый игровой объект описывается в классе, в котором прописываешь основную логику этого объекта. Грубо говоря, есть войн у которого есть health, damage, он может принимать дамаг и умирать. А есть игрок, который тот же войн, только управляется через userInput и есть враг, который управляется с помощью ии. Зачем делать дубляж кода для Врага и Игрока, если можно создать абстракцию (шаблон), которым ты опишешь общую логику двух объектов, а потом дополнишь в другом классе их особенности. Но ужаснее всего описывать логику врага и игрока в рамках одного класса..
Не совсем понимаю зачем нам сущность дробить на интерактор и репозиторий. Не проще ли реализовать сущность с помощью интерфейсов (интерактор и репозиторий) и мы также сможем всем этим управлять, только уже через интерфейсы и не надо будет дублировать инициализацию.
Автор похоже не из шарпа пришел в программироdание - стиль кода что то на JS похоже ))) Особенно скобки на одной строке и публичные поля с маленькой буквы )
Зачем вы придумываете всякие глупости? Архитектура должна помогать разработке, а не её запутывать. Вначале надо ставить цель - какие преимущества вы хотите получить, не нарушив ООП, а уже в рамках этого писать свой код.
Мне эта архитектура не понравилась, создание репозитория в MonoBehavior это зашквар. А где DI контейнер? А как же тесты потом гнать если всё во вьюхах? А почему mediator не применить для развязки? А почему Command и транзакционную обработку не применить, для модификации моделей? ... ??? не буду продолжать ??? ...
Данная информация всё ещё актуальна и полезна начинающим разработчикам (коим являюсь я)? Такой же вопрос к плейлисту "Устарело. На пересъёмку". Я начал смотреть, для новичка выглядит очень полезно, но название "устаревшее" немного смущает.
Спасибо, недавно начал изучать юнити с целью саморазвития в геймдеве и столкнулся с проблемой, что мало инфы про архитектуру и структуру проектов. Очень хотел бы увидеть архитектуру на каком то простом, но правильном продакшен примере, дабы не изобретать свой велосипед и не гавнокодить. Буду ждать следующие части, не забрасывай.
Это невероятно полезная тема. Большое спасибо Вам за эту серию уроков
Бро, ты - КРАСАВА!!!!!!!!!
Спасибо за ролик!
Это просто сокровище какое-то
Перерыла весь ютюб в поиске это инфы, спасибо!
Твой канал прямо находка, спасибо за видео, годнота.
Как не хватает такого материала на ютубе.) Однозначная подписка с колокольчиком. Только не останавливайся!
Сейчас небольшой перерыв, занимаюсь переездом, но скоро вернусь)
Поддерживаю твои слова! ) Честно, я даже не догадывался о таком способе. Меня это заставило переосмыслить свой код..
Ух, это было мощно!)
Продолжай в том же духе, у тебя все круто получается!!!
После прохождения junior pathway на unity learn не мог найти хорошие уроки, это то что мне нужно, спасибо за крутой обучающий контент!)
Обожаю этот канал
Спасибо за видео
Очень хорошая подача материала!!! Спасибо!!!
Очень интересно! Спасибо за урок!
Отличные и полезные уроки!👍
Ты крутой. Продолжай
Хороший урок.
Было бы круто если бы вы объяснили про абстракции и назначение абстракций объектам. Но и так не плохо!)
Добра вам)
Было очень интересно) Жду следующего видео!
Очень полезно!
оч полезно. Крутотень
Добрый день! Такой вопрос, вы оставили свойство Coins с публичным сеттером, правильно ли это? Мы же сможем изменить его из любого класса или я что то не понял...
"Репозиторий - это просто название, которое так уж сложилось в жизни что данные будут храниться в репозитории..."
Репозиторий - это вполне конкретный паттерн, который абстрагирует хранение данных от предметной логики. То есть предоставляет необходимый интерфейс для приложения с необходимыми ему методами (например: выбрать по id, выбрать все по какому-то признаку, удалить и тд), но само хранение данных делает деталью реализации.
Таким образом предметной области становится без разницы, где лежат данные (в scriptable object, в json на устройстве или на сервере) и как они обрабатываются.
Привет! После просмотра второго видео заметил сущность Bank и там статика. Зачем она нужна? Если можно просто в тестере обращаться что-то типо такого:
_bankInteractor.AddCoins(10);
Просто смысла в этой статике не вижу
Актуально ещё?
Хорошие у тебя лекции!
Подскажи пожалуйста, а есть у тебя что то по архитектуре сетевого взаимодействия? Организация обновления мира, состояний и т.д. Как организовать клиент-серверную архитектуру правильно, чтобы важные вычисления, влияющие на основной геймплей (например попадания) считались на сервере, а клиент занимался только отрисовкой красот?
А можно где-то найти мануалы или книги про то как нужно проектировать в Юнити или в других игровых движках?
Спустя 2 года спрошу, как успехи?
Для меня произошла какая-то магия
почему данные сохранились при повторном старте игры? где именно это прописано?
читая комментарии, посмотрев, какие слова люди употребляют в своих рассуждениях, внезапно почувствовал себя деревенским дурачком
Спасибо за видео. очень интересно. Хочу спросить один вопрос, такой уровень навыка программирование в рабочей сфере(например в компаниях) должен быть у каждого джуниора или это уже навыки мидла?
Это уже навыки мидла. Если джуниор умеет в архитектуру, то это скорее всего уже не джуниор)
@@gamedevlavka понятно, спасибо
@@gamedevlavka Раз тут вопрос про джуна) Что на практике нужно уметь джуну по юньке - чтобы устроиться на работу?) Я просто проект для портфолио делаю (полностью свой, а не по гайдам или тип того), парочка механик уже сделана (строительство, взаимодействие с интерфейсем, отправка советников в регионы и доставка в регионы к ним приказов (генерация курьера), управление камерой (2d), экономика базовая).
Смотря в какой геймдев рвешься. Больше требуются в мобильный.
- Опыт любых проектов приветствуется. Коммерческий проект в приоритете - все платформы
- Знание и понимание ООП, более менее красивый и читабельный код - все платформы
- Любой опыт запуска проекта в стор (Google Play, App Store) - мобильные платформы
- Умение использовать плагины (настраивать внутреигровые покупки, рекламу, аналитику) - все платформы, кроме монетизации.
- Умение собирать билды для GP и/или AppStore - мобильные платформы.
С таким набором можно куда-то приткнуться, но честно скажу, чем лучше код (четкое понимание ООП, использование паттернов в правильных местах, красивый и читаемый код), тем больше шансов. Даже если остальное недотягивает. Ибо остальное подучить - дело быстрое, а обучить программированию дольше.
@@gamedevlavka если дам доступ посмотреть на гитхабе проект, дашь оценку?)))
А можно ссылку на урок про который вы говорили про ивенты? не нашел у вас на канале
хороший урок и диктор, спасибо! Не подскажешь, твой подход имеет что-то общее с подходами MVVM или MVP или еще чем-то, или он совсем уникальный? Хочется понять немного близко ли это к стандартизированным подходам? Насколько такой подход востребован в студиях?
Заранее спасибо!
Есть общее с MVC, где View - это UI, controller это интерактор, в Model - это репозиторий. Так как я выводил эту архитектуру самостоятельно, то сходства весьма слабые, но очевидные. Сейчас перепиливаю архитектуру с нуля, делаю все гораздо лучше :)
@@gamedevlavka спасибо) надеемся тоже расскажете потом в видео новые версии, очень интересно было бы)
@@gamedevlavka я не гейм-дев, но с Android. То, что ты показал, относится к Clean Architecture. Клин - не замена MVC/MVP/MVVM/MVI. Клин - общий. В клине есть место для презентационного слоя, куда входят MV* типы архитектур.
И одно не понял с передачей sender в interactor: зачем интерактору знать про какие-то эффекты? Не должно ли это находиться в презентационном слое?
Доброго времени суток, вопрос по архитектуре. Разве должен bankInteractor знать кто его юзает? Его функция ведь в добавлении монеток, а знание кто его юзает - ему не нужно. Или создание некого "GameController" который раскидает по евентам функцию добавления монеток по кол-ву, и затем при условном подборе мы просто заколим евент на подобранную сумму - это плохо? Если да - то чем?
Спс
Ты когда то писал приложения для android? Репозиторий популярный шаблон там)
В конце прозвучала плохая фраза "отделять данные от их обработки". Это один из вариантов, но он приносит к сожалению много боли и дублирования кода. Ну а репозиторий желательно должен предоставлять доступ к сущности, а не к данным.
Ну в общем классика - MVC (Model, View, Controller)
Только что называется иначе
А каким образом в репозитории сохраняется информация после завершения программы?
загугли что такое PlayerPrefs в юнити
Почему ты сделал абстрактные классы, а не интерфейсы?
В ассете, ссылка на который есть в описании я сделал интерфейсы и абстрактные классы. В видео же я показываю идею, поэтому многие моменты сокращаю, и так как мне все равно нужно было реализовать некоторое поведение по-умолчанию, то для видео не стал писать интерфейсы. Но да, по-хорошему, лучше их использовать
В общем чем-то напоминает UI - BLL -DAL структуру из бизнес приложений.
что за ide?
Rider
Спасибо за видео!
Только есть вопрос: это ECS ? И если нет, то можно ли сочетать эту архитектуру и ECS?
Это однозначно не ECS. У ECS дргуие слои. E это Entity (Сущьность), C - Component (Компонет), S - System (Система). Они тоже взаимоимодействуют друг с другом. Но по особому
По сути очень напоминает MVC структуру. По сути репозиторий, это модель(Model). Interactor это контроллер(Controller), а вся остальная игровая логика, это представление(View).
Согласен, напоминает. Но я бы не стал проводить аналогию между View и геймплеем
Да на первый взгляд как mvc но если присмотреться то Вью нету по сути интерактор и репозиторий выполняют роль модели, геймплей возможно как контроллер а Вью просто нету)
@@Sv9zlsT я бы в качестве представления (view) предложил бы интерфейс, так как, по сути, это и есть представление игровых данных, то есть модели, которой управляет геймплей в качестве контроллера. Как вам такой вариант?
Интересно, но вот this глаз режет. Почему бы не соблюдать нотацию и начинать приватные поля с _ ? Райдер ведь подсказывает что this нужен был только в конструкторе. С _ решили бы проблему с this.
Вот здесь, я писал, почему я пишу this везде:
t.me/gamedevlavka/15
Да, я тоже удивился. Потому что привык к нижнему подчёркиванию.
тоже пишу с this.
Зачем ты используешь this при обращении к полям класса?
Методы и переменные находятся в единой зоне видимости в классе
Так это же обычный MVC, нет?
День добрый ! Интересно с вами пообщаться на тему совместной работы над проектом...
Приветствую! По таким вопросам удобнее общаться в телеграм: @vavilichev
В других курсах интеракторы называют сервисами, а репозиторий - ассет провайдером
Надеюсь список сущностей архитектуры будет собираться через рефлексию? Не зря же им как метка был сделан базовый абстрактный класс..., Хотя и через интерфейс можно было)
Не через рефлексию, через конфиги.. при помощи конфигов, можно делать наборы интеракторов и репозиториев для каждой сцены отдельно)
Правильно ли я понимаю, что файл "репозиторий" - по сути - база данных?
Скорее контейнер с данными. Их можно передавать и забирать откуда-то.
Мужик в сером на фоне красного ковра :)
Я дико извиняюсь,я просто хочу спросить,а обязательно писать ооп,вить когда мы прибегаем к ооп,мы подразумеваем,что мы сделаем некие инструменты,для наших целей,чтоб в итоге что то строить с помощью их.Ну если нам нужен функционал,мне кажется применять ооп подход крайне расточительно,почему я так говорю,если в дальнейшем мы не будем пользоваться этим инструментом,то такой подход просто теряет смысл ?
Все в разработке строится на ООП. Каждый игровой объект описывается в классе, в котором прописываешь основную логику этого объекта. Грубо говоря, есть войн у которого есть health, damage, он может принимать дамаг и умирать. А есть игрок, который тот же войн, только управляется через userInput и есть враг, который управляется с помощью ии. Зачем делать дубляж кода для Врага и Игрока, если можно создать абстракцию (шаблон), которым ты опишешь общую логику двух объектов, а потом дополнишь в другом классе их особенности. Но ужаснее всего описывать логику врага и игрока в рамках одного класса..
@@vlader776 Вот я про это и говорю.
Не совсем понимаю зачем нам сущность дробить на интерактор и репозиторий. Не проще ли реализовать сущность с помощью интерфейсов (интерактор и репозиторий) и мы также сможем всем этим управлять, только уже через интерфейсы и не надо будет дублировать инициализацию.
Автор похоже не из шарпа пришел в программироdание - стиль кода что то на JS похоже ))) Особенно скобки на одной строке и публичные поля с маленькой буквы )
Скорее, в компании, в которой он работает такой КодСтайл
ПОдписка)
Зачем столько лишних this?
Зачем вы придумываете всякие глупости? Архитектура должна помогать разработке, а не её запутывать. Вначале надо ставить цель - какие преимущества вы хотите получить, не нарушив ООП, а уже в рамках этого писать свой код.
Мне эта архитектура не понравилась, создание репозитория в MonoBehavior это зашквар. А где DI контейнер? А как же тесты потом гнать если всё во вьюхах? А почему mediator не применить для развязки? А почему Command и транзакционную обработку не применить, для модификации моделей? ... ??? не буду продолжать ??? ...
Данная информация всё ещё актуальна и полезна начинающим разработчикам (коим являюсь я)? Такой же вопрос к плейлисту "Устарело. На пересъёмку". Я начал смотреть, для новичка выглядит очень полезно, но название "устаревшее" немного смущает.
Я тоже бы сказал, что новичок. Но я бы рекомендовал лучше книги читать, в них больше правильных мыслей.
Сейчас видеоблогер снимает серию видео по созданию игры, рекоммендую к просмотру.