ограничения по времени. В популярные игры типа доты/старкрафта бОльшая часть людей играет много, но «заходами». В итоге подписка N-минут в месяц — самая неудобная из возможных
те самые популярные дота + ск2 + кс: го слишком чувствительны к пингу — а тут ещё латенси из-за особенностей системы. С вашей системой игроки играют в неравном положении и по-сути это обман игроков(хотя на безрыбье это и может кому-то пригодиться).
учитывая что для них не нужен мощный компьютер, playkey с учётом недостатков сказанных выше и вовсе скорее минус, чем плюс.
Плюсы:
игры с графикой и на «быстро пробежать, посмотреть сюжет и удалить» заходят на ура
Замечания:
Необходимость покупки игр отдельно
Нет «аренды» игр
Бесплатные популярные игры плохо подходят для этого сервиса(дота)
На данный момент для большей части геймеров, сервис скорее боль, чем панацея.
Странно, что нет ни слова про серию Fable — герой начинает маленьким мальчиком, а со временем становится известным героем. Мнение окружающих меняется, а сам герой может изменить мир (решения, которые он принимает став правителем в 3-ей части, хороший пример).
Ну а по теме: это просто не выгодно. Современные игры — пройти сюжетку полюбоваться свободой и купить следующую.
Сравните линейку игр BioWare: Baldur's Gate, Neverwinter Nights, Star Wars: Knights of the Old Republic, Jade Empire, Mass Effect, Dragon Age.
С каждой игрой всё меньше ролёвки и больше фильма.
По поводу спам-кликов и высокого APM в целом: обычно же делают, что каждое действие агента(которое не дает reward) уменьшает reward, из-за чего агент учится делать всё наиболее рационально. Интересно использовалось ли это в AlphaStar?
Мне кажется, тогда мы бы видели средний APM в районе 100, просто потому что в "ответственные" моменты он бы выдавал >2000 apm.
Впервые AI хоть как-то обыграл человека в эту игру, и в целом хоть в какую-то игру
такого рода.
OpenAI в доте?
AI сделанные без машинного обучения?
Есть сообщество которое соревнуется в "ботостроении" на основе первого старкрафте и показывают хорошие результаты, но обыгрываются профессионалами банальными тактиками, наподобие той, которой победил MaNa (варп-призма + обс)
Даже просто вот это наше overprobing
Я все ещё не определился — это баг, связанный с тем что они сначала специально тренировали только на добыче минералов (см. Материалы на их сайте) без "настоящих матчей" или они просто приспособились играть друг против друга ("мета", "баланс" и "стратегии" зависят в большОй степени от игроков) — потому что отличный контроль при атаке приведет к убийству рабочих.
Так же по поводу баланса — взгляните на юнитов которых строил бот — сталкер или сталкеры + дизрапторы — он тоже о многом говорит, так как эти юниты при нечеловеческом контроле гораздо лучше.
Я это к тому что люди у него не многому научатся. Его тактики — это тактики для идеального контроля, который пока ни один игрок в мире не может осуществить(и возможно не сможет никогда)
Также, по поводу "учиться у бота" — насколько ужасные размеры были в узких проходах — это отдельный разговор. Это такая ошибка, которую увидели игроки всех уровней.
Это офигенно в том числе и чисто эстетически.
Просто бот vs человек с огромной долей хайпа. Опять же посмотрите на любительских ботов для первого ск. Некоторые вещи они делают лучше, а как показала последняя игра с MaNa — он подвержен некоторым таким же хитростям
Злоупотребление подобными правилами является проблемой, да.
Как в примере с CoC, когда сторонние люди, не относящиеся к проекту и не вложившие в него больших усилий могут убрать с проекта человека, посветившего огромное количество времени и усилий этому проекту.
Но в пределах разумного эти правила необходимы для современного общества. Необходимо понимание того, что люди разные, у них свои страхи и переживания, и относиться к особенностям личности с уважением, не упрекая их в том что, в общем случае, тебя не касается(ориентация, цвет кожи, религия) и не оказывает негативного влияния на окружающих.
С проблемой пренебрежения нужно бороться чётко сформулировав границу между приемлемым и неприемлемым поведением. Например, чтобы удивленный возглас "Боже мой" считался устоявшимся фразеологизмом, не имеющем отношения к религии.
В целом, не следует из более формального общения делать драму (как же я теперь без "шуток про блондинок" и тому подобного). Я напоминаю, что речь идёт о рабочей среде.
Ваш список запрещенных шуток: про ориентацию, про пол, про религию, про воинскую обязанность(?)
Не мой, а краткий пересказ правил компании в которой я раньше работал.
От себя добавил бы ещё шутки про "пора рожать" для девушек и про детей в целом, потому что это деликатная тема, но, к сожалению, подобное тоже периодически всплывает.
У других людей другие запретные темы, в итоге придем к тому, что шутить вообще нельзя.
Смысл не столько в шутках, сколько в ущемлении людей. Для вас возможно это будет "просто шутка", а некоторых это может сильно зацепить. Та же тема про воинскую обязанность — некоторые просто посмеются, а человек может действительно переживать по этому поводу, что ему придётся расстаться со своими родственниками, друзьями и коллегами на год. Если задуматься, это достаточно депрессивная тема, поэтому не стоит "давить на больное".
Эти "запреты" скорее общие рекомендации, потому что шутки на эту тему зачастую бывают оскорбительными, либо болезненными, для многих людей. В остальном можно полагаться на собственные чувства.
Из важных запретных тем, которые я, к сожалению, забыл указать есть ещё "шутки" про инвалидность.
в итоге придем к тому, что шутить вообще нельзя.
Нужно понимать что вы не в баре с друзьями, а среди коллег, которые могут иметь разную ориентацию, религию, принадлежать разным культурам и быть по разному воспитанными. Поэтому темы для шуток желательно ограничить. Для вас, возможно, подобные шутки не значат ничего, а на моей памяти есть случай, когда девушку довели до слёз шуткой про то, что она ходила курить с другими сотрудниками. Таких случаев в рабочей среде быть не должно.
Программист ведь творческая личность, по-другому никак, и запретами его творчество можно только подавить. Ну и результат труда будет соответствующий.
Я не думаю что отказ от шуток которые могут задеть чувства других сотрудников помешает вам писать хороший код. А вот задетые чувства сотрудников могут негативно сказаться как на их производительности, так на межличностные отношения с командой. Этого нужно избегать, пускай и ценой "шуток".
Крайне не согласен с мнением изложенным в статье. По пунктам:
"Это должен быть матёрый сисадмин со стальными яйцами" — никто никому ничего не должен.
"который плачет от шуток про ориентацию" — это плохие шутки и их не должно быть в "рабочей среде". Ровным счётом как и половых (например про "тупых блондинок"), религиозных, относительно воинской обязанности сотрудников.
"что нельзя критиковать людей, нельзя вообще высказвать им негативную оценку" — да, нельзя. Человек приложил усилия и написал код. То что он не соотвествует какому-то требованию, о котором он мог и не знать — это уже другой разговор. Но в целом: "критиковать людей нельзя" — правильная точка зрения. Не забывайте что это для вас "программирование — это субкультура" или, скорее, "культ", а для большинства людей это просто работа, на которую они ходят просто потому что получают за это деньги. Оскорблять людей за их работу неправильно. Критиковать тоже нужно правильно.
По поводу оценки кода — меня учили не критиковать код, а указывать на более подходящие варианты, или проблемные моменты. Да, допустим, программист сделал обход связанного списка вместо доставания по хешу из ассоциативного массива. Не нужно говорить что "это говнокод", "это <плохое> решение" нужно сразу сказать что это можно сделать лучше.
Удивительно что многие поддерживают мнение указанное в статье. "IT-не детский сад, а место для суровых людей которые могут и 'куда-подальше послать' " — это плохое мнение, которое может отсеять потенциальных специалистов.
Не говоря уже о том, что в нашей профессии часто приходится общаться с людьми, а аргументы в статье говорят о том что хороший айтишник — тот который не знает как это правильно делать
Но автор с тем же фанатизмом "впихивает" SQL, где лучше сработал бы ML и говорит что SQL справляется лучше.
Скажем, человек купил пару обуви, солнцезащитные очки и книгу. В рассылке для него мы покажем обувь, солнцезащитные очки и книги. Это гораздо более уместно, чем посылать случайные вещи
Мне покажут обувь, когда я купил обувь; очки, когда я купил очки и случайные книги, когда я купил книгу.
В то же время ML мог показать товары, которые сочетаются с теми что я взял:
шнурки для обуви, одежду под цвет кроссовок, книги, которые покупают люди, у которых такие же интересы и т.д.
upd: те кто покупали телефоны в интернет магазинах сразу меня поймут — ты только добавил телефон в корзину, тебе уже советуют чехол, защитную пленку, PowerBank и автомобильную зарядку
Мне кажется, рекомендательная система — это одна из сильных сторон ML.
Смысл статьи как всегда: "не забивать гвозди отверткой и не закручивать молотком".
в любом языке в concurrent решение не быстрее обычного, при условии что они выполняются на одном ядре.
в любом языке регулярки — очень жирные, потому что они рассчитаны на гибкость.
пример с trim — тоже показывает что обобщенное решение, не быстрее конкретного.
Пожалуй, самый наглядный пример — это поиск элемента перебором, или бинарным поиском — зная, что все элементы упорядоченны, мы можем в разы ускорить поиск элемента
Поправьте, если ошибаюсь, но, вроде бы, стандарт IPv6 поддерживается многими устройствами уже давно.
Для большинства пользователей переход на IPv6 будет незаметен. (в один прекрасный день просто айпишник заменится на новый и всё)
upd: речь про пользовательские роутеры. как там у телекомопов — мне не ведомо.
Скорее "Акция Илона Маска" больше напоминает коллекционные издания игр — получаешь тоже самое, но ещё фигурку и книжечку, знатно переплатив себестоимость товаров…
Может быть, ICO появилось благодаря коллекционным изданиям игр? <сарказм>
Это реддит — самое добрый и самый злой сайт. У него специфичная аудитория и подобный тип бана ей очень подходит.
Да, возможно, это не этично, но давайте взглянем на плюсы:
тролли не получают "пищу" -> теряют интерес к данному ресурсу, что радует обычных пользователей
уменьшает количество спама, потому что в случае обычного бана, сделают очередной спам-аккаунт, а тут нужно проверять под другим логином.
По теме:
Я создал свой аккаунт на reddit.com порядка 2-х лет тому назад, постил периодически но потом длительно время им не пользовался. Некоторое время назад я написал несколько тем, после чего периодически отвечал на всяко-разные вопросы в субреддитах /r/gamedev /r/unity3d.
Возможно, вы нарушили "Posting Guidelines" сабреддита:
Promotion
Once-per-game feedback requests or release threads are OK, but a considerable history of participation on /r/gamedev is required. Must be a Text Post
На одном из книжных фестивалей взял "мангу" "Занимательная статистика" "Регрессионный анализ" там очень хорошо и наглядно рассказан(и показан) математический материал необходимый для понимания темы.
Проблем нет, если новых фич/кода не предвидется.
Проблемы начинаются, когда вы, например, придумаете повторяемые квесты с рандомным дропом, захотите сделать особенный лут для какого-нибудь ивента(например повысите вероятность получения вещей в 2 раза), а потом придумаете, что не только должна повышаться вероятность получения вещей, но и в некоторых случаях их количества(например 2 зелья здоровья, вместо одного, 20 монет вместо 10 и т.д.), или вероятность выпадения "уникального хэллоуинского/новогоднего наряда", а потом ещё и доп. лут к 23 февраля и 8 марта...
Это одна из настоящих проблем Coupling'а(сильной связанности). Если вы будете писать без DI(Dependency Injection, внедрения зависимостей), то вам придётся писать огромные if'ы и ваш элегантный код превратится в макаронный, а с DI проблем с синглтонами нет, потому что вы сможете сделать под каждый случай свой синглтон. Например сделаем interface LootManager и следующие наследники:
FixedLootManager — для дропа из квестовых монстров и сундуков из "кампании". Бросает ровно то что нам нужно.
RandomLootManager — ScriptableObject, который генерирует случайный лут для уровня данного уровня монстра
LevelDependentLootManager — SO, который генерирует лут в зависимости от уровня героя
HighierRatesLootManager — SO для генерации лута с увеличенными рейтами(шансом выпадения).
HalloweenSpecialLootManager — SO для генерации лута для хэллоуинских ивентов
Я боюсь, что это любой проект, который со временем обрастает кодом:
Сложности тестирования делают ваш код менее стабильным, а наличие God-Object'а и вовсе может привести к сложно обноруживающимся багам.
Более подробный ответ об проблемах и "альтернативах" я описал ниже.
Перечитал ещё раз свой комментарий и заметил, что из него плохо понятно чем плох первый пункт минусов синглтона(про единую ответственность).
Т.к. предыдущий коммент получился большой, решил написать отдельно:
Каждый класс должен выполнять ровно ту функцию, для которой он был создан. В случае с синглтоном тут две функции: управление своим жизненным циклом и "бизнесс-логика" вложенная в него.
Несмотря на то что "управление своим жизненным циклом" кажется простой задачей, всё становится гораздо сложнее с многопоточными приложениями.
Наш стильный маленький "бойлерплейт"(повторяющийся код, необходимый для правильного выполнения программы) обрастает синхронизациями, и прочими вещами, которые осложняют понимание бизнес-логики кода и повышают шансы на то, что кто-то ненароком его сломает.
Мой "основной" язык — Java, так что расскажу как дела обстоят там и почему правы и те люди, которые говорят что синглтон зло, и почему правы вы:
Нарушение принципа единственной ответственности
В Java (и скорее всего в C#) синглтон создает сам себя, хранит сам себя и делает свою бизнес логику. Это ужасно, это отвратительно, это плохо.
НО! В Unity этим занят сам движок. Вы только делаете ScriptableObject и сам движок управляет жизненным циклом синглтона. Про "God Object" поговорим дальше, пока считаем что эта проблема решена.
Singleton невозможно тестировать
Тесная связь
Эти проблемы связанны напрямую. Coupling(т.н. "связывание", оно же "сильная связанность") — это когда объект содержит другой объект. В итоге мы не может протестировать их по одиночке. Юнит тестирование класса аггрегирующего другой класс будет невозможно, т.к. мы будем завязаны на использование внутреннего объекта. Это тоже ужасно, отвратительно и плохо…
Но опять нам на выручку приходит игровой движок, который по совместительству выполняет роль Dependency Injection(внедрение зависимостей, DI).
Многие начинающие программисты на юнити используют его даже не подозревая этого, потому что оно настолько простое. Перетаскивание объектов в скрипты, Изменение их значений через UI — всё это внедрение зависимостей и эта простота не уменьшает возможности.
Хотите синглтон(ScriptableObject)? Пожалуйста! Но будет гораздо разумнее использовать наследование и встроенный DI.
Примеры:
Сделать разные свойства игры для разных сложностей: сделаем игру тетрис, три разных ScriptableObject'а описывающих разные значения высоты и ширины поля и скорости игры. В зависимости от выбранных настроек инжектим разные ScriptableObject'ы.
Сделать разные характеристики для юнитов в стратегии, для последующего теста и менять их только изменяя SO при создании юнита.
Сделать разные AI для разного поведения опонента в экономической стратегии: более агрессивный и более миролюбивый.
Каждый из приведенных выше примеров позволит протестировать разный ScriptableObject отдельно, и заменить их на Mock'и при тестировании классов, которые их используют.
При каждом изменении мы сможем заменить старый SO на новый, оставив старый, на случай "отката", если идея не взлетит.
Проблема с God-Object тоже пропадает при использовании DI.
Плюсы:
Замечания:
На данный момент для большей части геймеров, сервис скорее боль, чем панацея.
Ну а по теме: это просто не выгодно. Современные игры — пройти сюжетку полюбоваться свободой и купить следующую.
Сравните линейку игр BioWare: Baldur's Gate, Neverwinter Nights, Star Wars: Knights of the Old Republic, Jade Empire, Mass Effect, Dragon Age.
С каждой игрой всё меньше ролёвки и больше фильма.
По поводу спам-кликов и высокого APM в целом: обычно же делают, что каждое действие агента(которое не дает reward) уменьшает reward, из-за чего агент учится делать всё наиболее рационально. Интересно использовалось ли это в AlphaStar?
Мне кажется, тогда мы бы видели средний APM в районе 100, просто потому что в "ответственные" моменты он бы выдавал >2000 apm.
такого рода.
OpenAI в доте?
AI сделанные без машинного обучения?
Есть сообщество которое соревнуется в "ботостроении" на основе первого старкрафте и показывают хорошие результаты, но обыгрываются профессионалами банальными тактиками, наподобие той, которой победил MaNa (варп-призма + обс)
Я все ещё не определился — это баг, связанный с тем что они сначала специально тренировали только на добыче минералов (см. Материалы на их сайте) без "настоящих матчей" или они просто приспособились играть друг против друга ("мета", "баланс" и "стратегии" зависят в большОй степени от игроков) — потому что отличный контроль при атаке приведет к убийству рабочих.
Так же по поводу баланса — взгляните на юнитов которых строил бот — сталкер или сталкеры + дизрапторы — он тоже о многом говорит, так как эти юниты при нечеловеческом контроле гораздо лучше.
Я это к тому что люди у него не многому научатся. Его тактики — это тактики для идеального контроля, который пока ни один игрок в мире не может осуществить(и возможно не сможет никогда)
Также, по поводу "учиться у бота" — насколько ужасные размеры были в узких проходах — это отдельный разговор. Это такая ошибка, которую увидели игроки всех уровней.
Просто бот vs человек с огромной долей хайпа. Опять же посмотрите на любительских ботов для первого ск. Некоторые вещи они делают лучше, а как показала последняя игра с MaNa — он подвержен некоторым таким же хитростям
"в низких лигах" — это вплотную до мастер лиги?
С ограниченным пулом 5-ых игроков в доте уже обыграл OpenAi. Ещё летом.
Злоупотребление подобными правилами является проблемой, да.
Как в примере с CoC, когда сторонние люди, не относящиеся к проекту и не вложившие в него больших усилий могут убрать с проекта человека, посветившего огромное количество времени и усилий этому проекту.
Но в пределах разумного эти правила необходимы для современного общества. Необходимо понимание того, что люди разные, у них свои страхи и переживания, и относиться к особенностям личности с уважением, не упрекая их в том что, в общем случае, тебя не касается(ориентация, цвет кожи, религия) и не оказывает негативного влияния на окружающих.
С проблемой пренебрежения нужно бороться чётко сформулировав границу между приемлемым и неприемлемым поведением. Например, чтобы удивленный возглас "Боже мой" считался устоявшимся фразеологизмом, не имеющем отношения к религии.
В целом, не следует из более формального общения делать драму (как же я теперь без "шуток про блондинок" и тому подобного). Я напоминаю, что речь идёт о рабочей среде.
Не мой, а краткий пересказ правил компании в которой я раньше работал.
От себя добавил бы ещё шутки про "пора рожать" для девушек и про детей в целом, потому что это деликатная тема, но, к сожалению, подобное тоже периодически всплывает.
Смысл не столько в шутках, сколько в ущемлении людей. Для вас возможно это будет "просто шутка", а некоторых это может сильно зацепить. Та же тема про воинскую обязанность — некоторые просто посмеются, а человек может действительно переживать по этому поводу, что ему придётся расстаться со своими родственниками, друзьями и коллегами на год. Если задуматься, это достаточно депрессивная тема, поэтому не стоит "давить на больное".
Эти "запреты" скорее общие рекомендации, потому что шутки на эту тему зачастую бывают оскорбительными, либо болезненными, для многих людей. В остальном можно полагаться на собственные чувства.
Из важных запретных тем, которые я, к сожалению, забыл указать есть ещё "шутки" про инвалидность.
Нужно понимать что вы не в баре с друзьями, а среди коллег, которые могут иметь разную ориентацию, религию, принадлежать разным культурам и быть по разному воспитанными. Поэтому темы для шуток желательно ограничить. Для вас, возможно, подобные шутки не значат ничего, а на моей памяти есть случай, когда девушку довели до слёз шуткой про то, что она ходила курить с другими сотрудниками. Таких случаев в рабочей среде быть не должно.
Я не думаю что отказ от шуток которые могут задеть чувства других сотрудников помешает вам писать хороший код. А вот задетые чувства сотрудников могут негативно сказаться как на их производительности, так на межличностные отношения с командой. Этого нужно избегать, пускай и ценой "шуток".
Крайне не согласен с мнением изложенным в статье. По пунктам:
"Это должен быть матёрый сисадмин со стальными яйцами" — никто никому ничего не должен.
"который плачет от шуток про ориентацию" — это плохие шутки и их не должно быть в "рабочей среде". Ровным счётом как и половых (например про "тупых блондинок"), религиозных, относительно воинской обязанности сотрудников.
"что нельзя критиковать людей, нельзя вообще высказвать им негативную оценку" — да, нельзя. Человек приложил усилия и написал код. То что он не соотвествует какому-то требованию, о котором он мог и не знать — это уже другой разговор. Но в целом: "критиковать людей нельзя" — правильная точка зрения. Не забывайте что это для вас "программирование — это субкультура" или, скорее, "культ", а для большинства людей это просто работа, на которую они ходят просто потому что получают за это деньги. Оскорблять людей за их работу неправильно. Критиковать тоже нужно правильно.
По поводу оценки кода — меня учили не критиковать код, а указывать на более подходящие варианты, или проблемные моменты. Да, допустим, программист сделал обход связанного списка вместо доставания по хешу из ассоциативного массива. Не нужно говорить что "это говнокод", "это <плохое> решение" нужно сразу сказать что это можно сделать лучше.
Удивительно что многие поддерживают мнение указанное в статье. "IT-не детский сад, а место для суровых людей которые могут и 'куда-подальше послать' " — это плохое мнение, которое может отсеять потенциальных специалистов.
Не говоря уже о том, что в нашей профессии часто приходится общаться с людьми, а аргументы в статье говорят о том что хороший айтишник — тот который не знает как это правильно делать
Я хз откуда цифра в 30 гб на современные игры, т.к. у меня игр 5 стоит на ~100 гб.
SSD для работы — хорошая штука.
Для системы SSD тоже заходит хорошо.
Но он явно не идеален и порой RAID0 (или RAID#) из N HDD неплохо заходит.
Для себя решил систему + работу ставить на SSD, медиа на HDD
Но автор с тем же фанатизмом "впихивает" SQL, где лучше сработал бы ML и говорит что SQL справляется лучше.
Мне покажут обувь, когда я купил обувь; очки, когда я купил очки и случайные книги, когда я купил книгу.
В то же время ML мог показать товары, которые сочетаются с теми что я взял:
шнурки для обуви, одежду под цвет кроссовок, книги, которые покупают люди, у которых такие же интересы и т.д.
upd: те кто покупали телефоны в интернет магазинах сразу меня поймут — ты только добавил телефон в корзину, тебе уже советуют чехол, защитную пленку, PowerBank и автомобильную зарядку
Мне кажется, рекомендательная система — это одна из сильных сторон ML.
Смысл статьи как всегда: "не забивать гвозди отверткой и не закручивать молотком".
в любом языке в concurrent решение не быстрее обычного, при условии что они выполняются на одном ядре.
в любом языке регулярки — очень жирные, потому что они рассчитаны на гибкость.
пример с trim — тоже показывает что обобщенное решение, не быстрее конкретного.
Пожалуй, самый наглядный пример — это поиск элемента перебором, или бинарным поиском — зная, что все элементы упорядоченны, мы можем в разы ускорить поиск элемента
Поправьте, если ошибаюсь, но, вроде бы, стандарт IPv6 поддерживается многими устройствами уже давно.
Для большинства пользователей переход на IPv6 будет незаметен. (в один прекрасный день просто айпишник заменится на новый и всё)
upd: речь про пользовательские роутеры. как там у телекомопов — мне не ведомо.
Скорее "Акция Илона Маска" больше напоминает коллекционные издания игр — получаешь тоже самое, но ещё фигурку и книжечку, знатно переплатив себестоимость товаров…
Может быть, ICO появилось благодаря коллекционным изданиям игр? <сарказм>
Это реддит — самое добрый и самый злой сайт. У него специфичная аудитория и подобный тип бана ей очень подходит.
Да, возможно, это не этично, но давайте взглянем на плюсы:
По теме:
Возможно, вы нарушили "Posting Guidelines" сабреддита:
Вы просто не умеете её готовить :)
На одном из книжных фестивалей взял "мангу" "Занимательная статистика" "Регрессионный анализ" там очень хорошо и наглядно рассказан(и показан) математический материал необходимый для понимания темы.
Проблем нет, если новых фич/кода не предвидется.
Проблемы начинаются, когда вы, например, придумаете повторяемые квесты с рандомным дропом, захотите сделать особенный лут для какого-нибудь ивента(например повысите вероятность получения вещей в 2 раза), а потом придумаете, что не только должна повышаться вероятность получения вещей, но и в некоторых случаях их количества(например 2 зелья здоровья, вместо одного, 20 монет вместо 10 и т.д.), или вероятность выпадения "уникального хэллоуинского/новогоднего наряда", а потом ещё и доп. лут к 23 февраля и 8 марта...
Это одна из настоящих проблем Coupling'а(сильной связанности). Если вы будете писать без DI(Dependency Injection, внедрения зависимостей), то вам придётся писать огромные if'ы и ваш элегантный код превратится в макаронный, а с DI проблем с синглтонами нет, потому что вы сможете сделать под каждый случай свой синглтон. Например сделаем interface LootManager и следующие наследники:
и т.д.
Согласитесь, это выглядит получше.
Я боюсь, что это любой проект, который со временем обрастает кодом:
Сложности тестирования делают ваш код менее стабильным, а наличие God-Object'а и вовсе может привести к сложно обноруживающимся багам.
Более подробный ответ об проблемах и "альтернативах" я описал ниже.
Перечитал ещё раз свой комментарий и заметил, что из него плохо понятно чем плох первый пункт минусов синглтона(про единую ответственность).
Т.к. предыдущий коммент получился большой, решил написать отдельно:
Каждый класс должен выполнять ровно ту функцию, для которой он был создан. В случае с синглтоном тут две функции: управление своим жизненным циклом и "бизнесс-логика" вложенная в него.
Несмотря на то что "управление своим жизненным циклом" кажется простой задачей, всё становится гораздо сложнее с многопоточными приложениями.
Наш стильный маленький "бойлерплейт"(повторяющийся код, необходимый для правильного выполнения программы) обрастает синхронизациями, и прочими вещами, которые осложняют понимание бизнес-логики кода и повышают шансы на то, что кто-то ненароком его сломает.
Мой "основной" язык — Java, так что расскажу как дела обстоят там и почему правы и те люди, которые говорят что синглтон зло, и почему правы вы:
В Java (и скорее всего в C#) синглтон создает сам себя, хранит сам себя и делает свою бизнес логику. Это ужасно, это отвратительно, это плохо.
НО! В Unity этим занят сам движок. Вы только делаете ScriptableObject и сам движок управляет жизненным циклом синглтона. Про "God Object" поговорим дальше, пока считаем что эта проблема решена.
Эти проблемы связанны напрямую. Coupling(т.н. "связывание", оно же "сильная связанность") — это когда объект содержит другой объект. В итоге мы не может протестировать их по одиночке. Юнит тестирование класса аггрегирующего другой класс будет невозможно, т.к. мы будем завязаны на использование внутреннего объекта. Это тоже ужасно, отвратительно и плохо…
Но опять нам на выручку приходит игровой движок, который по совместительству выполняет роль Dependency Injection(внедрение зависимостей, DI).
Многие начинающие программисты на юнити используют его даже не подозревая этого, потому что оно настолько простое. Перетаскивание объектов в скрипты, Изменение их значений через UI — всё это внедрение зависимостей и эта простота не уменьшает возможности.
Хотите синглтон(ScriptableObject)? Пожалуйста! Но будет гораздо разумнее использовать наследование и встроенный DI.
Примеры:
Каждый из приведенных выше примеров позволит протестировать разный ScriptableObject отдельно, и заменить их на Mock'и при тестировании классов, которые их используют.
При каждом изменении мы сможем заменить старый SO на новый, оставив старый, на случай "отката", если идея не взлетит.
Проблема с God-Object тоже пропадает при использовании DI.