Убейте менеджеров, контроллеры и системы. Декомпозиция компонентов в Unity / Unity Best Practices #3

[@kraken1649]

Лол замазал надпись активации винды?

[@FloatingGames]

@Злая собака . Гааав-гав-гав можно без покупок на время, хотя правиль и ссовестью купить

[@unreal-illia]

@@FloatingGames пиши в дс Unreal#9394 скину прогу на всегда дает активацию)

[@Roman-09111]

Вчера убил менеджеров! Сегодня на меня хотят завести уголовное дело ))))))

[@rahatbakum7852]

хпххпхх

[@AtlantZ]

Увидел ошибку в if за минуту до того, как Рома об этом начал говорить. Мой внутренний программист чуть с ума не сошёл. Когда Рома обратил на это внимание - выдохнул с облегчением.

[@avocadocoder185]

Роман, отличная подача, так держать! Никто на отечественном Ютубе так здраво не рассказывает про такие темы в Unity и C#. По крайней мере я не встречал

[@Lynatik001]

название менеджер плохо? у меня есть такая структура, игра автобатлер 5 на 5. (автобой на сервере происходит) Есть клас гейм в нем - _battleManager(клас).SimulateBattle(осн функа) - ну и лист активных боев, и еще пару методов + подписка на старт и конец боя(под сомнением что там нужны) - далее в нем battle(класс BattleSimulation).Initialize С проброской в него персонажей и евентсистем и уже в BattleSimulation приисходит симуляция боя и вызов всех событий (типа окончания боя и тдп) а раз на сервере все то мне нужно каждое действие записывать. Думал сначало сделать класс команды но вышло чуть интереснее(нейронка посоветовала) -Не знал что так можно извращатся с событиями. теперь у меня история боев ето список событий. а каждое событие ето обьект что содержит все нужные данные. (тик, тип события(атака, движение и тд) и прочие параметры Как вам такая логика:?)

[@Shumtakatak]

В asp net core используется model + service + controller, и внедряются зависимости

[@snatvb]

Мини ошибочка, у тебя в спавнере var coin есть, хотя спавнер никакого отношения к монеткам не имеет, это мелочь конечно Вообще я gamemanager использую как entry point для взаимодействия с другими элемнтами, например я написал модуль работы с сетью, и сделал инстанс в GameManager, он же в свою очередь синглтон, а вот модуль я не могу сделать синглтоном, ибо его можно протестировать задав разные конфиги и сопрягать 2 инстанса в тесте. Придется писать какую-то синглтоновскую обертку, что в свою очередь порадит по сути такую же шляпу, как и GameManager, только вот "хламосброс" у меня будет один, вместо нескольких. Если есть ответ, как это можно получше организовать, расскажи, буду рад))

[@DimaBriquez]

Вряд ли кто то ответит но всё-таки. Есть же музыка и настройки разве для них не подойдёт аналог менеджера?

[@zheka9877]

Роман, как мне кажется, хотел передать мысль, что делать класс отвечающий за всё - не самая лучшая идея. Если у тебя, например, несколько источников музыки (музыка игры и музыка в машине), то это явно разные классы, не пихаем все в один. Но, если у тебя, например есть только музыка уровня, то делать менеджер можно, потому что он будет отвечать только за музыку уровня и не за чью больше

[@DimaBriquez]

@@zheka9877 Но все ровно есть классы у которых должны быть ссылки. Например настройки, там может быть громкость эффектов, громкость музыки, Громкость озвучки и т.п.

[@zheka9877]

@@DimaBriquezну и там по идее нужно отделить UI (переключатели, галочки и т.д.) от самих ссылок. Да и ссылки разные: настройки графики, музыки, управления... Я точно не знаю, я не профессиональный разработчик, но, думаю, хранить ты никакие ссылки не будешь, а настройки у тебя в json будут лежать, а необходимые компоненты потом в Awake() будет забирать эти настройки

[@soulsteppe4358]

Небольшое замечание - звук при записи чутка громче надо сделать, а то с телефона на максимальной громкости очень тихо слышно (особенно если на машине едешь, или в общественном транспорте)

[@Migiwara-Yo]

а можно ли делать класс Scene manager в котором я буду только переключать сцены?

[@AHEKDOTbl]

Почему бы класс не назвать "SceneLoader" тогда?

[@zzz3781]

Курс на котором он будет учитЬся*

[@mihaelnew676]

Делаю GameManager, но он у меня управляет только игровыми состояниями. В чём проблема.

[@horrest790]

проблема в том, как пилят курсы и как раздуваются всякие геймманагеры в обучающих материалах, что потом оседает у людей как норма

[@alexkruglov7548]

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

[@ScrewY0UguyS]

@@alexkruglov7548 а как в таком случае правильно проектировать управление игровыми состояниями? Лучшее решение, пришедшее мне в голову - это статические методы, вроде GameOver() или LevelCompleted(). Очень интересен правильный подход к этому вопросу.

[@СлавныйЛехаОбломов]

Благодарю!

[@АлександрОмельченко-ы1у]

SRP как всегда не верно трактуется он не о том говорит, блин, для кого Чистую Архитектуру писали хз

[@dadlord689]

Я услышал в начале правильные слова про контроллер который делает всё (я столкнулся именно с таким проектом: там и Zenject и имитация single responsibility и вся херня). Но дальше смотреть боюсь потому что скорее всего будет лютый бред как и во всех отечественных видосах. Если человек не понимает то А: ничего нормального не сделает, Б: ничему ты его не научишь. Все эти эпические туторы с разбором кода, заданиями из пальца и подобная дичь - до лампочки. Ничего ты не поймёшь пока думать не начнёшь. А если уже своя башка работает - туторы не нужны, читай доки.