Unity - базовая архитектура для любого проекта.
HTML-код
- Опубликовано: 17 сен 2024
- В ролике пример базовой архитектуры с использованием dependency injection практически для любой игры.
Ссылка на гит проекта
github.com/Haf...
Вторая часть:
• Unity - архитектура, ч...
Игры в конце ролика, опубликованные на Яндексе (осторожно реклама).
Сами игры провалились, и ссылка тут исключительно для примера использования архитектуры из ролика.
Fey Archer: yandex.ru/game...
Tower Of Nightmares: yandex.ru/game...
#разработкаигр #unity #gamedev #програмирование
![Роботы не должны выглядеть как люди [Veritasium]](/img/1.gif)
Ссылка на гит проекта
github.com/Hafune/BootstrapProject
git upd. рефлексия удалена из MonoConstruct
Вторая часть:
ruclips.net/video/NboD_LfSaUg/видео.html
Игры в конце ролика, опубликованные на Яндексе (осторожно реклама).
Fey Archer: yandex.ru/games/#app=200426
Tower Of Nightmares: yandex.ru/games/#app=249851
Классно, еще раз пересмотрел) жаль совсем мало просмотров, даже странно( загуглил пишут типа ютифай помогает, типа официальная реклама, без накрута.
Спасибо.
Да просмотров маловато... но и канал совсем молодой )
Надо будет что-нибудь ещё про этот подход снять, что бы раскрыть тонкости в полной мере потребуется не один ролик.
А уровни как загружать динамично ? Ну или сюжетку, это я про проекты уже среднего размера, так как иметь по 50-70 сцен не будет удобно и уж точно не оптимально
Если у тебя действительно будет 50-70 сцен, то почему бы и не продолжать загружать их так же.
Но если хочется иметь несколько сцен загруженных одновременно можно попробовать адитивную загрузку сцен.
Так же в платформере у меня были уровни состоящие из нескольких случайных больших кусков соединенных последовательно, эти куски уже были выполнены в виде префабов которые я инстансил на сцене в нужном порядке и контролировал их состояние вкл/выкл для экономии производительности.
@@Hafune сцены как по мне при загрузке и релизе через даже адресблы много памяти жрут, лучше как префабы все загружать, и потом релизить через адресы но тут уже внутренние компоненты нужно будет сконектит с кор логикой
Внедрение контейнера в компоненты или классы, нафиг разрушает саму идею DI и делает все классы зависимыми от контейнера - проще тогда просто юзать статику или сервис локатор, по смыслу будет тоже самое
Всё таки не соглашусь.
Когда ты юзаешь статику ты не можешь подменить её, контейнер можешь.
Сервис локатор требует от тебя класс с полным набором всех сервисов в виде полей этого класса что серьёзно усложняет его подмену.
Пробрасывание зависимостей в конструктор это тот же самый Di, класс получает зависимости по ключу.
Пробрасывая контейнер я даю возможность классу получить те же самые зависимости по ключу но без прописывания в конструкторе кучи аргументов этих зависимостей и тот же самый контейнер ты можешь подменить создав новый со своими оверайднутыми зависимостями и сделав инстансинг уже от него.
Знаю что те же K-Syndicate говорят что нельзя прокидывать контейнер, но я лишь рассказываю свой опыт который надеюсь кому-нибудь поможет.
Наверняка это не лучший подход для работы в команде, но для соло разраба думаю вполне.
@@Hafune Прекрасно в статике подменяется что угодно, нормально собранный сервис локатор, ничем не отличается от выбранного вами способа получения зависимости. Если есть архитектура в приложении, то кучи зависимостей в конструкторах и не должно быть - архитектура для этого и нужна