Увидел ошибку в if за минуту до того, как Рома об этом начал говорить. Мой внутренний программист чуть с ума не сошёл. Когда Рома обратил на это внимание - выдохнул с облегчением.
Роман, отличная подача, так держать! Никто на отечественном Ютубе так здраво не рассказывает про такие темы в Unity и C#. По крайней мере я не встречал
Мини ошибочка, у тебя в спавнере var coin есть, хотя спавнер никакого отношения к монеткам не имеет, это мелочь конечно Вообще я gamemanager использую как entry point для взаимодействия с другими элемнтами, например я написал модуль работы с сетью, и сделал инстанс в GameManager, он же в свою очередь синглтон, а вот модуль я не могу сделать синглтоном, ибо его можно протестировать задав разные конфиги и сопрягать 2 инстанса в тесте. Придется писать какую-то синглтоновскую обертку, что в свою очередь порадит по сути такую же шляпу, как и GameManager, только вот "хламосброс" у меня будет один, вместо нескольких. Если есть ответ, как это можно получше организовать, расскажи, буду рад))
Небольшое замечание - звук при записи чутка громче надо сделать, а то с телефона на максимальной громкости очень тихо слышно (особенно если на машине едешь, или в общественном транспорте)
Роман, как мне кажется, хотел передать мысль, что делать класс отвечающий за всё - не самая лучшая идея. Если у тебя, например, несколько источников музыки (музыка игры и музыка в машине), то это явно разные классы, не пихаем все в один. Но, если у тебя, например есть только музыка уровня, то делать менеджер можно, потому что он будет отвечать только за музыку уровня и не за чью больше
@@zheka9877 Но все ровно есть классы у которых должны быть ссылки. Например настройки, там может быть громкость эффектов, громкость музыки, Громкость озвучки и т.п.
@@DimaBriquezну и там по идее нужно отделить UI (переключатели, галочки и т.д.) от самих ссылок. Да и ссылки разные: настройки графики, музыки, управления... Я точно не знаю, я не профессиональный разработчик, но, думаю, хранить ты никакие ссылки не будешь, а настройки у тебя в json будут лежать, а необходимые компоненты потом в Awake() будет забирать эти настройки
Для своих проектов и каких-нибудь прототипов - вполне себе, большее уже можно считать оверинженерингом. Для проектов требуемых расширяемости и гибкости, и для проектов в которых работает несколько программистов - уже не очень, т.к игровое состояние - понятие растяжимое, и при добавлении этих состояний, или при добавлении различных фич/модулей класс обязательно разрастется.
@@alexkruglov7548 а как в таком случае правильно проектировать управление игровыми состояниями? Лучшее решение, пришедшее мне в голову - это статические методы, вроде GameOver() или LevelCompleted(). Очень интересен правильный подход к этому вопросу.
Я услышал в начале правильные слова про контроллер который делает всё (я столкнулся именно с таким проектом: там и Zenject и имитация single responsibility и вся херня). Но дальше смотреть боюсь потому что скорее всего будет лютый бред как и во всех отечественных видосах. Если человек не понимает то А: ничего нормального не сделает, Б: ничему ты его не научишь. Все эти эпические туторы с разбором кода, заданиями из пальца и подобная дичь - до лампочки. Ничего ты не поймёшь пока думать не начнёшь. А если уже своя башка работает - туторы не нужны, читай доки.
Лол замазал надпись активации винды?
@Злая собака . Гааав-гав-гав можно без покупок на время, хотя правиль и ссовестью купить
@@FloatingGames пиши в дс Unreal#9394 скину прогу на всегда дает активацию)
Увидел ошибку в if за минуту до того, как Рома об этом начал говорить.
Мой внутренний программист чуть с ума не сошёл.
Когда Рома обратил на это внимание - выдохнул с облегчением.
Вчера убил менеджеров! Сегодня на меня хотят завести уголовное дело ))))))
хпххпхх
Роман, отличная подача, так держать! Никто на отечественном Ютубе так здраво не рассказывает про такие темы в Unity и C#. По крайней мере я не встречал
Мини ошибочка, у тебя в спавнере var coin есть, хотя спавнер никакого отношения к монеткам не имеет, это мелочь конечно
Вообще я gamemanager использую как entry point для взаимодействия с другими элемнтами, например я написал модуль работы с сетью, и сделал инстанс в GameManager, он же в свою очередь синглтон, а вот модуль я не могу сделать синглтоном, ибо его можно протестировать задав разные конфиги и сопрягать 2 инстанса в тесте. Придется писать какую-то синглтоновскую обертку, что в свою очередь порадит по сути такую же шляпу, как и GameManager, только вот "хламосброс" у меня будет один, вместо нескольких. Если есть ответ, как это можно получше организовать, расскажи, буду рад))
Небольшое замечание - звук при записи чутка громче надо сделать, а то с телефона на максимальной громкости очень тихо слышно (особенно если на машине едешь, или в общественном транспорте)
В asp net core используется model + service + controller, и внедряются зависимости
Вряд ли кто то ответит но всё-таки.
Есть же музыка и настройки разве для них не подойдёт аналог менеджера?
Роман, как мне кажется, хотел передать мысль, что делать класс отвечающий за всё - не самая лучшая идея. Если у тебя, например, несколько источников музыки (музыка игры и музыка в машине), то это явно разные классы, не пихаем все в один. Но, если у тебя, например есть только музыка уровня, то делать менеджер можно, потому что он будет отвечать только за музыку уровня и не за чью больше
@@zheka9877 Но все ровно есть классы у которых должны быть ссылки.
Например настройки, там может быть громкость эффектов, громкость музыки, Громкость озвучки и т.п.
@@DimaBriquezну и там по идее нужно отделить UI (переключатели, галочки и т.д.) от самих ссылок. Да и ссылки разные: настройки графики, музыки, управления...
Я точно не знаю, я не профессиональный разработчик, но, думаю, хранить ты никакие ссылки не будешь, а настройки у тебя в json будут лежать, а необходимые компоненты потом в Awake() будет забирать эти настройки
а можно ли делать класс Scene manager в котором я буду только переключать сцены?
Почему бы класс не назвать "SceneLoader" тогда?
Благодарю!
Делаю GameManager, но он у меня управляет только игровыми состояниями. В чём проблема.
проблема в том, как пилят курсы и как раздуваются всякие геймманагеры в обучающих материалах, что потом оседает у людей как норма
Для своих проектов и каких-нибудь прототипов - вполне себе, большее уже можно считать оверинженерингом. Для проектов требуемых расширяемости и гибкости, и для проектов в которых работает несколько программистов - уже не очень, т.к игровое состояние - понятие растяжимое, и при добавлении этих состояний, или при добавлении различных фич/модулей класс обязательно разрастется.
@@alexkruglov7548 а как в таком случае правильно проектировать управление игровыми состояниями? Лучшее решение, пришедшее мне в голову - это статические методы, вроде GameOver() или LevelCompleted(). Очень интересен правильный подход к этому вопросу.
Курс на котором он будет учитЬся*
SRP как всегда не верно трактуется он не о том говорит, блин, для кого Чистую Архитектуру писали хз
Я услышал в начале правильные слова про контроллер который делает всё (я столкнулся именно с таким проектом: там и Zenject и имитация single responsibility и вся херня). Но дальше смотреть боюсь потому что скорее всего будет лютый бред как и во всех отечественных видосах. Если человек не понимает то А: ничего нормального не сделает, Б: ничему ты его не научишь. Все эти эпические туторы с разбором кода, заданиями из пальца и подобная дичь - до лампочки. Ничего ты не поймёшь пока думать не начнёшь. А если уже своя башка работает - туторы не нужны, читай доки.