Есть ли случаи, когда глобалы / синглтоны полезны при разработке игр? [закрыто]

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

Так есть ли случаи, когда глобальные переменные или синглтоны действительно полезны при разработке игр?

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

Определенно не исчерпывающий список, но здесь идет:

Cons

• Пожизненное управление . Синглеты и глобалы могут запускаться до инициализации ключевых систем (например, кучи), в зависимости от того, как вы их настроили. Если вам когда-нибудь захочется их разорвать (например, полезно, если вы отслеживаете утечки), вы должны быть осторожны с порядком разрыва или начать разбираться с вещами типа феникс-синглтонов . (См. Статический порядок инициализации фиаско .)
• Контроль доступа . Должен ли рендеринг иметь только постоянный доступ к игровым данным, тогда как обновление становится неконстантным? Это может быть сложнее обеспечить с помощью синглетонов и глобалов.
• Гос . Как отметил Кай, сложнее функционально разложить и преобразовать синглтоны, чтобы они вообще работали в архитектуре без разделяемой памяти. Это также может повлиять на производительность других типов систем NUMA (доступ к памяти не локальный). Синглтоны обычно представляют централизованное состояние и, таким образом, являются антитезой преобразований, которые делаются легче благодаря чистоте.

Либо за, либо против

• Параллелизм . В параллельной среде синглтоны могут быть либо болью (вы должны учитывать проблемы гонки данных / повторного входа), либо благословением (проще централизовать и рассуждать о блокировке и управлении ресурсами). Умное использование таких вещей, как локальное хранилище потоков, может несколько смягчить потенциальные проблемы, но обычно это не простая проблема.
• Codegen (в зависимости от компилятора, архитектуры и т. Д.): Для наивной одноэлементной реализации создания при первом использовании вы можете оценивать дополнительную условную ветвь для каждого доступа. (Это может сложить.) Несколько глобальных переменных, используемых в функции, могут привести к переполнению литерального пула . Подход "структура всех глобальных переменных" может сэкономить место в пуле литералов: только одна запись в основе структуры, а затем смещения, закодированные в инструкциях загрузки. Наконец, если вы избегаете глобальных и синглтонов любой ценой, вам, как правило, нужно использовать хотя бы немного дополнительной памяти (регистры, стек или кучу) для передачи указателей, ссылок или даже копий.

Pros

• Простота . Если вы знаете, что перечисленные выше недостатки не так сильно на вас влияют (например, вы работаете в однопоточной среде для платформы с одним ЦП), вы избегаете некоторой архитектуры (например, вышеупомянутой передачи аргументов). Синглеты и глобалы могут быть более понятны для менее опытных программистов (хотя может быть проще использовать их неправильно).
• Управление жизненным циклом (снова). Если вы используете «структуру глобалов» или какой-то другой механизм, отличный от запроса «создать по первому запросу», вы можете легко читать и детально контролировать порядок инициализации и уничтожения. Вы до некоторой степени автоматизируете это или управляете им вручную (управлять им может быть за или против, в зависимости от количества глобалов / синглетонов и их взаимозависимостей).

Мы часто используем «структуру глобальных синглетонов» в наших портативных устройствах. Названия ПК и консолей имеют тенденцию меньше полагаться на них; мы переключимся больше на архитектуру событий / обмена сообщениями. При этом заголовки ПК / консоли все еще часто используют центральный TextureManager; так как он обычно оборачивает один общий ресурс (память текстур), это имеет смысл для нас.

Если вы сохраняете свой API относительно чистым, то может быть не так уж сложно выполнить рефакторинг из (или в!) Единственного шаблона, когда вам нужно ...

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

Я бы сказал, что сам по себе синглтон-дизайн вообще бесполезен. Глобальные переменные, безусловно, могут быть полезны, но я бы предпочел, чтобы они были спрятаны за хорошо написанным интерфейсом, чтобы вы не знали об их существовании. С одиночками вы определенно знали об их существовании.

Я часто использую глобальные переменные для вещей, к которым нужен доступ через двигатель. Мой инструмент производительности - один хороший пример, который я использую по всему движку для вызова. Звонки просты; ProbeRegister (), ProbeHit () и ProbeScoped (). Их реальный доступ немного сложнее и использует глобальные переменные для некоторых вещей.

Основная проблема с глобальными и плохо реализованными синглетонами - неясные ошибки в конструкции и деконструкции.

Так что, если вы работаете с примитивами, которые не имеют эти проблемы или хорошо осведомлены о проблеме с указателем. Затем они могут безопасно использоваться.

Глобалы имеют свое место, также как и gotos, и их не следует выбрасывать из рук, а использовать их с осторожностью.

Это хорошее объяснение есть в Руководстве по стилю Google C ++

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

Одиночки полезны для причинения проблем себе и другим. Чем более глобальное состояние вы представите, тем больше у вас проблем с корректностью кода, обслуживанием, расширяемостью, параллелизмом и т. Д. Просто не делайте этого.

Я склонен рекомендовать использовать какой-либо DI / IoC-контейнер с настраиваемым управлением временем жизни вместо синглетонов (даже если вы используете менеджер времени жизни «одного экземпляра»). По крайней мере, тогда легко заменить реализацию для облегчения тестирования.

Если вам нужны функции сохранения памяти в синглтоне, возможно, вы можете попробовать шаблон проектирования с облегченной конструкцией?

http://en.wikipedia.org/wiki/Flyweight_pattern

Что касается многопоточных проблем, упомянутых выше, было бы довольно просто предусмотрительно реализовать механизм блокировки ресурсов, которые могут совместно использоваться потоками. http://en.wikipedia.org/wiki/Read/write_lock_pattern

Синглтоны - отличный способ сохранить общее состояние в раннем прототипе.

Они не являются «серебряной пулей» и имеют некоторые проблемы, но они очень полезны для определенных состояний интерфейса / логики.

Например, в iOS вы используете синглеты для получения [UIApplication sharedApplication], в cocos2d вы можете использовать его для получения ссылок на определенные объекты, такие как [CCNotifications sharedManager], и лично я обычно начинаю с синглтона [Game sharedGame], где я могу состояние хранилища, которое совместно используется многими различными компонентами.

Вау, это интересно для меня, так как у меня никогда не было проблем с одиночной структурой. Мой текущий проект представляет собой игровой движок C ++ для Nintendo DS, и я реализую множество утилит аппаратного доступа (например, VRAM Banks, Wifi, два графических движка) в качестве единичных экземпляров, поскольку они предназначены для обертывания глобального C функции в базовой библиотеке.

Только когда у вас есть элемент, который имеет только один контроллер, но обрабатывается несколькими модулями.

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

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

Синглтоны - лучший глобальный ИМО и, следовательно, правильный инструмент.

Используйте это экономно!