Паттерн Единая Точка Входа (или Entry Point). Как использовать в Unity?
Vložit
- čas přidán 7. 07. 2024
- Поддержать канал:
www.donationalerts.com/r/game...
paypal.me/gamedevlavka
Коротенькое 🤡 видео с одним из самых важных на мой взгляд паттернов проектирования игр на Unity. Почему-то о нем мало кто говорит, по крайней мере мне он достаточно долго не попадался на глаза, тем не менее, единая точка входа используется повсеместно. Поэтому я решил, что не рассказать о данном паттерне было бы преступлением со стороны Лавки Разработчика.
Смотрим, комментируем, ставим лайки, подписываемся на канал!
___
Лавка Разработчика в других соц. сетях, добавляйтесь!
t.me/gamedevlavka - телеграм канал Лавки Разработчика
t.me/gamedevtavern - ламповый чат
/ discord - дискорд
gamedevlavka - вконтактик
__________
0:00 Вступление
0:30 Рассказываю подробности примера
1:27 Собственно, рассказ о паттерне Единая Точка Входа
Спасибо за видео! Хоть некоторые коментаторы пишут, что эта тема ну у ж очень очевидная, но не стоит забывать, что на ютубе много туторов без архитектуры. Просто сплошные монобехи. Хочу увидеть ещё урок по архитектурным паттернам.
Ничего себе как быстро и по теме, побольше бы таких
Отличное видео! Спасибо😉
огромное спасибо! всё понятно, шикардос
О вот этот видосик я ждал 😊
Спасибо за видео!
На Unity использую Composition Root + Zenject для реализации Entry Point. Очень удобно для резолва сервисов и статичных данных. Но видео интересное, поделюсь им со знакомыми. Благодарю за труды❤
База
Да, так часто делается :)
Посоветуете гайд для чайника? С Zenject шапочно знакома, про Composition Root впервые слышу
о, и ты тут) какой же маленький мир
Спасибо, все понятно)
Полезные знания, спасибо
Хотелось бы видеть конкретную реализацию обработки проверки наличия сервисов.
И мне казалось, что точку входа логично делать еуниверсальной и единственной, а не разбивать на три класса по тиму загрудаемой сцены. Но возможно я ошибаюсь. В любом случае, сейчас именно так стаоаюсь реализовать.
Подумаю, как можно об этом рассказать. И нет, я в видео опомянул, что точка входа - это место разворачивается приложения или модуля. Сцена в данном примере является отдельным таким модулем
@@gamedevlavka спасибо!
Пока вкуриваем 5 видео про архитектуру, после будем паттерны смотреть)
Спасибо за урок!
Как потом между сценами эти данные перенести? после выгрузки бутстрапа все ссылки потеряются
Немного не понял, про фейковые сервисы. Тот же Zenject или VContainer строит граф зависимостей. Чтобы прокинуть сервис в стартер, нужно и сам стартер прокинуть в DI. Ошибки же будут сыпаться при первой возможности, мол не смог зарезолвить, тк. нет такого типа в контейнере, тк. запуск не с бутстрапа был.
Тут моя ошибка, я не проговорил, что феейковые сервисы - исключительно для тестов в редакторе. Чтобы не запускать и не проходить несколько сцен до текущей. При этом некоторые сервисы требуют наличие ссылок на Project сервисы, в этом случае (в редакторе, лучше используя дефайны) можно создать фейковые сервисы, чтобы сцена работала
По моему, Entry Point это не паттерн, а основа любой архитектуры.
Я бы сказал, что это справедливо для разработки в .Net, там сложно без него чтолибо построить. Unity по-умолчанию не имеет ограничений по точкам инициализации, поэтому не для всех это очевидно
Просьба сделать видео о сохранении в проекте в целом. Все рассказывают о том как сохранить в файл, но не говорят о системе сохранений в игре в целом. Например нужно сохранять всю игру целиком в реалтайме (например майнкрафт). Как лучше подобное реализовать? Также интересно будет посмотреть о передаче данных между сценами (например 1 сцена на все уровни и данные передаются из меню).
Понимаю запрос, это не одним видео делается, чтобы понятно было. Ну либо одним, но длинным)
Сделаю, как нибудь, там очень много нюансов)
@@gamedevlavka Спасибо
Зачем тебе сохранение в реалтайме? Это в любом случае будет очень медленно, делать сохранение каждую секунду. Чтобы сохранять сцену есть различные способы, все зависит от того что ты хочешь сохранить, данные пользователя? PlayerPrefs. Состояние сцены? Будь добр напиши свой парсер сцены, который будет парсить объекты твоей сцены в файл, будь то json или xml, да хоть обычный txt. Как парсить сцену? Определиться с данными, которые ты хочешь сохранять, по сути минимум это позиция, вращение и размер, а дальше уже пожеланию. Для лучшей загрузки всего этого используешь addressables, это позволит относительно быстро загружать сохраненную сцену, в том числе и в билде.
Чтобы передавать данные между сценами существуют такие вещи как static переменные, DonDestroyOnLoad, Локальное сохранение данных в файл или PlayerPrefs
@@Hatemsla многое сказано, с частью я согласен, с частью - есть нюансы. Вообще весь ответ на вопрос можно свести к тому: а чего хочется? Сохранение бывает по сейвпоинтам (сохраняется не каждый объект на сцене, как в метроидваниях, например), по уровням (тут вообще мало инфы хранится), открытый мир (тот случай с сохранением сцены), сохранение в облако, хранение и сохранение прямо на сервере (майнкрафт), сохранение в в один файл, в множество файлов, в префсы, в общем вариантов целая куча, и самый главный вопрос тут - какой нужен для конкретного проекта.
Передавать данные между сценами нужно через архитектурные решения, так правильнее сказать. А какие - это уже тоже очень емкий вопрос. Думаю, подниму его на курсе, который делаю. И когда-нибудь он будет готов, но не сегодня :)
@@gamedevlavka В целом да, вообще сохранение чего либо в игре это концептуальный вопрос и он зависит от многого, банально, если игра сетевая то принципы сохранения и хранения данных будет разительно(или нет) отличаться от сингл решения. Способов, подходов и решений много, я лишь перечисли то, что так или иначе придется использовать, если нужна система сохранения
Start можно запускать как корутину? Ты открыл мне новый мир)
Его ещё можно как асинхронный метод определить
Правильно понимаю, что инициализируемые объекты в первой сцене мы должны определить в DontDestroyOnLoad ? Чтоб они были доступны и в другой сцене?
Это зависит от архитектуры, но да, один из вариантов в DontDestroyOnLoad()
@@gamedevlavka Но это то, что мне первое в голову пришло. Теперь встал вопрос, как еще можно обеспечить доступность, того же Zenject и в других сценах, наиболее распросраненные практики?
@@user-dh4qw7qz8v Zenject уже есть свой подход, что здесь называется Entry Point - называется Context. Есть Project Context и Scene Context'ы. То есть все что здесь рассказано, можно через Zenject фреймворк делать. Подробнее в самой документации Zenject
@@HizusHiz можно, при этом в Zenject есть и ручная инициализация, что превращает его в инструмент, а не контроллер. Такие подходы тоже использовал, не всегда внутри zenject можно эффективно контролировать порядок. Так что тут все гибко, но в целом да, можно EntryPoint и через контекст в Zenject делать
@@gamedevlavka да, согласен, что при этом надо учитывать нюансы реализации фреймворка, что не всегда удобно
Делал по этому подходу игру zigzag выходит прикольно, все удобно и очень понятный код для изменений и расширений, но когда я дошел до OnCollision и похожих методов то понял, что не могу таким подходом сделать банальную вещь как проверить коснулись ли объекты друг друга, так как такие методы по умолчанию принимают в параметр объект на котором висит скрипт. Может есть какой-то другой подход при единой точке входа.
А в чем проблема? Объект на котором висит скрипт есть, OnColission есть, если сработал, значит столкнулись. Не пойму в каком месте проблема?
@@gamedevlavka OnCollisionEnter у меня в классе "инпутпоинт" объекты передают через инспектор, но чтобы OnCollisionEnter сработал он должен висеть на объекте с РБ и коллайдером и выходит что он просто не срабатывает.
@@vladislavsatanov6548 что-то ты не так понял концепцию. Монобехи и скрипты на них существуют и живут себе на сцене. В том числе некий скрипт, который висит на объекте с RB, который будет триггерить колизию. Он же в свою очередь может прокидывать событие выше в бизнес логику, например: столкнулись два объекта и у них должны отняться жизни, вот они в бизнес логику и говорят:
SomeFeature.ObjectsCollide(object1, object2)
Это как пример. И все
@@gamedevlavka Спасибо, попробую.
мне видится, что это не патерн, а больше как некая техника.
"стартуй в одной точке". это хорошо, полезно и актуально для начинающих.
доростут дальше - будут использовать Zenject.
-
снимайте плиз и дальше видео на аудиторию с разным уровнем. многим новичкам это полезно.
Некая техника - и есть паттерн. Паттерн это принцип, техника, шаблон действий. Так что тут все ок.
Насчёт зенжекта - он также реализует этот паттерн. А если нет, то у меня для вас плохие новости, зенжект значит используется неэффективно и странно)
___
Спасибо, буду стараться)
самое главное не сказал: как обеспечить чтобы скрипт entrypooint загрузился как первый, т.к. никогда у тебя на сцене не будет один скрипт. а так в целом, если человек знает про что реч то понятно и правильно :)
Можно не дергать окна интерфейса туда-сюда во время разговора? Честно говоря раздражает))
Поддерживаю!
А как при таком подходе инициализировать сервисы, которые о своей готовности сообщают в колбеках? Как колбеки стыкуют с корутинами? Ну и плюс при таком подходе, получается, придется всеми объектам на сцене вешать какой-нибудь скрипт, который будет блочить их деятельность, пока инициализация до них не дойдет и не запустит их. Как будто геморройненько звучит.
1. Запускаешь корутину, асинк что-то асинхронное, чтобы подождать пока сервисы проинициализируются и будут готовы. Вариантов на самом деле множество, нужно проявить смекалку и подобрать наиболее подходящий в текущей обстановке.
2. Не нужно всем объектам вешать никаких скриптов, они должны приводиться в рабочее состояние через инициализацию, не они кого-то ждут, чтобы запуститься, а их запускают, когда это необходимо
ударение режет слух, па́ттерн
Это настолько интуитивно понятно и очевидно, что удивительно, если кто-то не "изобрел" этот паттерн сам и пытался подготавливать фичи в своей игре как-то по-другому.
Да много кто пытался по-другому. Я пытался по-другому:
Сначала куча MonoBexxx, каждый на объект, ссылки пробрасывал эдитором (поскольку Unity допускает YOLO-подход, а всякие туториалы для простоты демонстрируют именно его, возникало ощущение, что так и надо).
Далее, когда даже небольшой проект превратился в лютую срань (кто бы мог подумать), подход изменился на "Одна фича - один объект" (по-моему какой-то из обучающих Unity проектов (которые с хаба докачиваются) демонстрировал тоже самое), жить стало проще.
Далее довелось поработать не с Unity, никакого крепления скриптов на GameObjectы, естественно, не было (как и самих GameObjectов) и только тогда пришло понимание, как нужно делать.
Для тех кто начинает с Unity ни разу не очевидно, что должна быть какая-то точка входа.
@@ichbinschlange Абсолютли эгрии, сам через такое же прошел, не рекомендую :)
@@ichbinschlange дело не в самом Unity. Вы верно заметили, что официальные туториалы в основном игнорируют архитектурные вопросы. Или подают их очень своеобразно.
@@andrey_aka_skif, нож только инструмент, это ясно, но тут как-то не возникает мысль, будто делаешь что-то не то, пока не случается затык. За это хочется упрекнуть движок. Те же нативные андроид-приложения пляшут от сцены (от откна, в рамках разработки) и не только они, Microsoft-технологии поступают так же.
@@ichbinschlange MVVM это тоже своеобразная вещь. Её смысл понятен, но паттерн загоняет тебя в определенные рамки. Шаг в сторону, и тут же жесткий тупняк. Особенно, если ты не разработчик подобных приложений, а захотел сделать небольшой специфичный инструмент.
Данный паттерн проектирования не описан в гоф, что делает его использование весьма сомнительным. В Википедии более 100 паттернов и антипаттернов и почти каждый программист пробует написать свой паттерн.
Данный паттерн применяется в веб разработке (возможно, отсюда пошло красивое название точки входа как бутстрап?). Напомню, что в веб мы посылаем и получаем данные, т.е. генерация данных каждый раз происходит с нуля (есть варианты - догрузка данных - аджакс, реактивные фреймворки, но не суть).
Это особенность работы веб приложений.
В десктопных программах, какой и является юнити (мы же генерируем игру для десктопа?), мы имеем почти все данные у себя на компьютере. Поэтому использование данного паттерна не является необходимым. Мы можем проинициализировать всё сразу и один раз.
Один раз загрузить в память все менюшки, один раз загрузить настройки игрока. У нас всё уже есть на локальной машине - нам никуда не надо делать постоянные запросы, загружать данные по требованию пользователя. Уверен, что на менюшки и настройки игрока и прочую мелочь хватит памяти современных устройств.
Более того - юнити всё грузит сам. Текстура на объекте, а объект на сцене? Много объектов, коллайдеров ..чего угодно. Когда мы загружаем сцену, мы же не пишем - загрузи объект 1, загрузи коллайдер на объекте 1... мы пишем - юнити загрузи сцену, а юнити сам всё загружает. Нам осталось только написать корутину проверки процента загрузки сцены и вывести это как прогрессбар.
В конце добавлю, что такое разбиение, особенно присвоение игроку инпута, инвентаря "извне" нарушает принципы ООП, а конкретно инкапсуляцию.
В конечном итоге произойдет путаница в инициализациях, зависимостях, последовательностях.
Интересно, как вы приклеили свои домыслы к моему видео. Вы можете относиться к паттерну как угодно, я никого не заставляю его использовать. Но личная статистика такова: на более чем 80% проектов (выборка более 30 проектов) был использован паттерн единая точка входа.
Не нужно думать, что современные устройства потянут "все, что угодно". Мобильная разработка (которая превалирует над всеми остальными платформами) диктует правила оптимизации. Оптимизация на мобилках это очень большой раздел знаний разработки на юнити, и расписывать его здесь я не стану, информацию модно найти при желании.
Очень похоже, что опыта в работе над крупными проектами у вас либо нет, либо недостаточно, чтобы понять, чем опасна хаотическая инициализация подсистем. Да, юнити грузит часть ресурсов самостоятельно, и это сильно упрощает некоторые процессы. Но это лишь один из аспектов инициализации.
Совершенно не понял, каким образом инициализация игрока с инпутом нарушает инкапсуляйию. Я и слова не сказал о том, как это реализуется. Всё, что вы сказали - это какая-то ваша фантазия, которой вы не поделились
Вот с этого места подробнее. В чём же присвоение извне нарушает инкапсуляцию? А как же инверсия управления из SOLID и внедрение зависимостей? А TDD как же?
Про веб тоже интересно. Веб разве ограничен фронтом? А как же бэк? В asp.net приложение стартует аналогичным образом. Билдер собирает приложение из сервисов, только потом запускает. Такая сборка происходит не при каждом обращении к контроллеру, а именно при старте приложения.
@@andrey_aka_skif а вы не задумывались что наследование нарушает инкапсуляцию? Тем более все перечисленные вами методики.
А вы про солид...
Очень частая ошибка мидл разработчика, яростно увлеченного паттернами (нет, не толкать их куда не надо он эту стадию уже прошел), а пытаться применять их во всех областях, технологиях и решениях.
Про веб - скажите asp нет пхп пайтон что то там ещё собирает все свои модули где? Оно загружает модули и исходный код (нет ну а вдруг) на клиентскую машину пользователя, подымает там локальный сервер и отображает страницу или...или всё делает у себя, а пользователю отдает только хтмл, картинки, жс скрипты. Нам не надо ничего собирать в юнити - у нас всё тут.
@@gamedevlavka У меня есть ещё пара фантазий. Не писать имена полей и переменных начиная с _ _isLoading и перестать писать f как магическую букву в конце значений переменных. Есть спецификация языка и стандарты майкрософт. Есть язык со строгой типизацией. Вам всё дали - пользуйтесь.
@@NewUser78654 Без f в конце литералов для float переменных вообще-то не скомпилируется ничего, это как раз требование спецификации языка. По поводу префикса для private полей вот выдержка из свежего соглашения микрософта: "Используйте верблюдовый регистр ("camelCasing") при именовании private, internal полей и добавьте к ним _ префикс"
Контексты зенжекта и есть ентри поинт
Спасибо за видео!