Наглядность работы скриптов я делаю через логи) не помню, есть в этом видео или нет, но в основном через логи. Этого достаточно, чтобы понять, что все работает и минимум времени, чтобы показать ту самую наглядность)

Ответил на последнем стриме, видео будет когда-то)

Не наследовать класс от MonoBehaviuor?

@@redfox7193 уже не актуально

Синглтон неплохо подходит под задачу интеграции наружних сервисов: синглтон рекламы, платёжки, стим, аналитика и др. Всё остальное - на свое усмотрение, но игрок например - это, если вдаваться в абстракцию, персонаж с управлением. Поэтому обычно, его не делают синглтоном, т.к. все может поменяться. Но если тебе не страшно переделывать огромный кусок, если что, или ты вовсе не собираешься этого делать - то пользуйся, пожалуйста)

Т.к. в юнити низкий порог входа, то многие начинающие создают GameManager. Видимо юнити сделали эту шестеренку для них (честно говоря, ума не приложу, для чего). GameManager непонятно что делает, поэтому это плохо. Что он менеджерит? Игру? В каком смысле? Загрузка сцен? Тогда почему не SceneManager? Уровень? То есть LevelManager? Вообще менеджер непонятно что делает. Что значит менеджерить? Вот поэтому классы со словом Managet не приветствуются. Потому что непонятно что они делать должны

Как минимум два аргумента: 1. Это может стать бесконтрольным. Ваш проект может превратиться в месиво синглтонов, потому что "это же удобно, и у меня никогда не будет больше одного экземпляра этого класса". Бесконтрольное использование синглтона может вылиться в проблему номер 2. 2. Внезапно нужно все-таки создать еще один экземпляр чего-то, что было синглтоном. Например игрок. Вдруг поступило предложение делать локальный мультиплеер. И всё, весь проект накрывается медным тазом, потому что переделывать с синглтона игрока будет долго, мучительно и больно.

@@gamedevlavka а по каким критериям определить подходящие и неподходящие для паттерна случаи?

Всегда нужно думать, как обойтись без него, это лучший вариант. Однако, его можно использовать в модулях, например: аналитика, класс самой игры Game (это из урока по архитектуре, который выйдет завтра), управление рекламой в мобильном приложении, управление внутреигровыми покупками - то, что запускается и инициализируется единожды и существует на протяжении всей игровой сессии.

@@gamedevlavka спасибо за ответы! 🙏

Не согласен с автором видео. Объяснение не очень подробное про то, почему плохо. Но не думаю, что смогу лучше. Классический пример, перезагрузка игры без выключения игры (накатываем прогресс другого игрока на устройство, обновляем вход через социальную сеть, игрок просто хочет все начать сначала). С синглотнами получается боль, потому что нужно вручную контролировать, что все данные очищаются. Либо писать, instance =null, instance = new Bank. Так же создавая синглтоны, мы говорим, что они создадуться лениво. Лениво - это когда они создаются не на старте игры, а при первом использовании (когда вызовем Bank.Instance). А теперь представьте, что синглтонам нужны еще синглтоны внутри, а тем тоже нужны синглтоны, еще и еще, вложенность синглтонов. И все они инициализируются в свои какие-то моменты времени. Вы просыпаетесь внезапно утром и понимаете, что когда в середине боя вы подбираете монетку - происходит дикий пролаг синглтонов, потом вы убиваете противника - еще пролаг. И вы не можете явно контролировать когда создавать синглтоны и какие классы их используют. А теперь игрок нажимает "Сброс прогресса", зависимости уничтожились не в том порядке, в котором создавались - произошел null reference или мы уничтожили не старый синглтон, а новый... мы даже не можем понять "а тот ли это синглтон". Да мы не можем даже понять какие синглтоны использует класс, не посмотрев внимательно на 200 строк и не зацепив глазом все методы и все строчки с SomeSingleton.Instance. А если в класс добавляем новый синглон - нужно не забыть его прокинуть в очистку. Вы начинаете разбираться и понимаете, что вы не можете контролировать ваш код. Не можете контролировать зависимости. Вы плачете. P.s. Синглтоны это не плохо, имхо, не нужно при любом раскладе их не использовать. Нужно попробовать, понять где можно и где нельзя. Синглтон понятный и простой паттерн, я видел большие проекты с синглтонами и все было в порядке. Вопрос в применимости и умению готовить

Будет, записал в план)

@@gamedevlavka потрясающе) ждём

Это вопрос архитектуры. Один синглтон не может содержать абсолютно все ссылки, это неудобно и неправильно. Смотри уроки по архитектуре, там я буду об этом говорить

@@gamedevlavka ну не все, а самые часто вызываемые, уроки конечно посмотрю. Давно толковых каналов не попадалось

Я тож так думаю, но подумал, что это я чего-то не шарю .-.

Ключевое слово return разве не прерывает метод?

@@def6141 точно!)

@@def6141 так вообще можно писать? Это считается нормой? Или лучше иф-элз юзать?

@@Kawabatushka конечно так можно писать) в данном случае иф-элз лишняя проверка.

Нет, так не происходит. Статическое поле - это переменная принадлежащая классу, а не его объекту, только и всего. Там подобных действий под капотом не происходит, и на производительность не влияет.

@@gamedevlavka Спасибо! Я ошибался.

В идеальном мире таких штук должно быть минимальное количество)

Если я правильно понял вопрос, то это интеллектуальный набор редактора кода)

посоветуйте канал, который Вы считаете лучше