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