Спасибо за видео! Хоть некоторые коментаторы пишут, что эта тема ну у ж очень очевидная, но не стоит забывать, что на ютубе много туторов без архитектуры. Просто сплошные монобехи. Хочу увидеть ещё урок по архитектурным паттернам.

огромное спасибо! всё понятно, шикардос

На Unity использую Composition Root + Zenject для реализации Entry Point. Очень удобно для резолва сервисов и статичных данных. Но видео интересное, поделюсь им со знакомыми. Благодарю за труды❤

Отличное видео! Спасибо😉

Ничего себе как быстро и по теме, побольше бы таких

О вот этот видосик я ждал 😊

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

Спасибо, все понятно)

Полезные знания, спасибо

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

Пока вкуриваем 5 видео про архитектуру, после будем паттерны смотреть)

Спасибо за урок! Как потом между сценами эти данные перенести? после выгрузки бутстрапа все ссылки потеряются

Немного не понял, про фейковые сервисы. Тот же Zenject или VContainer строит граф зависимостей. Чтобы прокинуть сервис в стартер, нужно и сам стартер прокинуть в DI. Ошибки же будут сыпаться при первой возможности, мол не смог зарезолвить, тк. нет такого типа в контейнере, тк. запуск не с бутстрапа был.

Просьба сделать видео о сохранении в проекте в целом. Все рассказывают о том как сохранить в файл, но не говорят о системе сохранений в игре в целом. Например нужно сохранять всю игру целиком в реалтайме (например майнкрафт). Как лучше подобное реализовать? Также интересно будет посмотреть о передаче данных между сценами (например 1 сцена на все уровни и данные передаются из меню).

По моему, Entry Point это не паттерн, а основа любой архитектуры.

Start можно запускать как корутину? Ты открыл мне новый мир)

Правильно понимаю, что инициализируемые объекты в первой сцене мы должны определить в DontDestroyOnLoad ? Чтоб они были доступны и в другой сцене?

самое главное не сказал: как обеспечить чтобы скрипт entrypooint загрузился как первый, т.к. никогда у тебя на сцене не будет один скрипт. а так в целом, если человек знает про что реч то понятно и правильно :)

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

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

Можно не дергать окна интерфейса туда-сюда во время разговора? Честно говоря раздражает))

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

Это настолько интуитивно понятно и очевидно, что удивительно, если кто-то не "изобрел" этот паттерн сам и пытался подготавливать фичи в своей игре как-то по-другому.

ударение режет слух, па́ттерн

Данный паттерн проектирования не описан в гоф, что делает его использование весьма сомнительным. В Википедии более 100 паттернов и антипаттернов и почти каждый программист пробует написать свой паттерн. Данный паттерн применяется в веб разработке (возможно, отсюда пошло красивое название точки входа как бутстрап?). Напомню, что в веб мы посылаем и получаем данные, т.е. генерация данных каждый раз происходит с нуля (есть варианты - догрузка данных - аджакс, реактивные фреймворки, но не суть). Это особенность работы веб приложений. В десктопных программах, какой и является юнити (мы же генерируем игру для десктопа?), мы имеем почти все данные у себя на компьютере. Поэтому использование данного паттерна не является необходимым. Мы можем проинициализировать всё сразу и один раз. Один раз загрузить в память все менюшки, один раз загрузить настройки игрока. У нас всё уже есть на локальной машине - нам никуда не надо делать постоянные запросы, загружать данные по требованию пользователя. Уверен, что на менюшки и настройки игрока и прочую мелочь хватит памяти современных устройств. Более того - юнити всё грузит сам. Текстура на объекте, а объект на сцене? Много объектов, коллайдеров ..чего угодно. Когда мы загружаем сцену, мы же не пишем - загрузи объект 1, загрузи коллайдер на объекте 1... мы пишем - юнити загрузи сцену, а юнити сам всё загружает. Нам осталось только написать корутину проверки процента загрузки сцены и вывести это как прогрессбар. В конце добавлю, что такое разбиение, особенно присвоение игроку инпута, инвентаря "извне" нарушает принципы ООП, а конкретно инкапсуляцию. В конечном итоге произойдет путаница в инициализациях, зависимостях, последовательностях.

Контексты зенжекта и есть ентри поинт

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