Are there cases where globals/singletons are useful in game development? [closed]

Question

I know that having global variables or singleton classes creates cases that can be difficult to test/manage and I have been busted in using those patterns in code but often times you gotta ship.

So are there cases where global variables or singletons are actually useful in game development?

Answer 1

These things can always be useful. Whether or not it's the prettiest or safest solution is another matter, but I think game development involves a certain degree of pragmatism.

Answer 2

Definitely a non-exhaustive list, but here goes:

Cons

• Lifetime management. Singletons and globals may like to start up before key systems (e.g. heap) are initialized, depending on how you set them up. If you ever want to tear them down (useful if you're doing leak tracking, for instance) you have to be careful about the teardown order or start getting into things like phoenix singletons. (See static initialization order fiasco.)
• Access control. Should rendering only have const access to game data, while update gets non-const? This may be harder to enforce with singletons and globals.
• State. As Kaj pointed out, it's harder to functionally decompose and transform singletons to work at all in a non-shared-memory architecture. It also has potential performance implications for other types of NUMA systems (accessing memory that isn't local). Singletons usually represent centralized state, and thus are the antithesis of transforms that are made easier by purity.

Either pro or con

• Concurrency. In a concurrent environment, singletons can either be a pain (you must consider data race / reentrancy issues) or a blessing (it's easier to centralize and reason about locking and resource management). Clever use of things like thread local storage can mitigate potential issues somewhat, but it is not usually an easy problem.
• Codegen (depending on compiler, architecture, etc): For a naive create-on-first-use singleton implementation, you may be evaluating an extra conditional branch for each access. (This can add up.) Multiple globals used in a function may bloat the literal pool. A "struct of all globals" approach may save space in the literal pool: only one entry to the base of the struct, and then offsets encoded in the load instructions. Finally, if you're avoiding globals and singletons at all costs, you generally need to use at least a little extra memory (registers, stack, or heap) to pass pointers, references, or even copies around.

Pros

• Simplicity. If you know the cons listed above don't affect you as much (e.g. you're working in a single-threaded environment for a single CPU handheld platform), you avoid some architecture (such as the aforementioned argument-passing). Singletons and globals may be easier to understand for less experienced coders (although it may be easier to use them incorrectly).
• Lifetime management (again). If you use a "struct of globals" or some mechanism other than a create-on-first-request, you can have easy to read and fine-grained control over initialization and destruction order. You automate this to some degree, or manually manage it (having to manage it may be a pro or a con, depending on the number of globals/singletons and their inter-dependencies).

We use a "struct of global singletons" a lot in our handheld titles. PC and console titles tend to rely on them less; we'll switch more toward an event-driven/messaging architecture. That having been said, the pc/console titles still often use a central TextureManager; since it usually wraps a single shared resource (the texture memory) this has made sense for us.

If you keep your API relatively clean, it might not be too terribly hard to refactor out of (or into!) a singleton pattern when you need...

Answer 3

They can be very useful, especially during prototyping or experimental implementation, but in general we prefer passing references around for manager like structures, that way you at least have some control over where they are accessed from. The biggest problem with globals and singletons (in my opinion) is that they are not very multithread friendly, and code that uses them is much harder to port to non shared memory, like SPU's.

Answer 4

I would say that the singleton design itself isn't useful at all. Global variables can definetly be useful but I'd rather see them hidden behind a well-written interface so that you aren't aware of their existence. With singletons you are definetly aware of their existence.

I often use global variables for things that need access all through out an engine. My performance tool is one good example which I use all over the engine to call. The calls are simple; ProbeRegister(), ProbeHit() and ProbeScoped(). Their real access is a little bit more tricky and uses global variables for some of their things.

Answer 5

The main problem with globals, and poorly implemented singletons is obscure construction & deconstruction bugs.

So if you work with primitives which don't have these issues or are very aware of the issue with a pointer. Then they can be used safely.

Globals have their place, same as gotos and should not be dismissed out of hand but instead used with care.

There is a good explanation of it in the Google C++ Style Guide

Answer 6

Globals are useful while quickly prototyping a system that requires some state between function calls. Once you've established that the system works, move the state into a class and make the functions into methods of that class.

Singletons are useful for causing problems to yourself and others. The more global state you introduce, the more issues you will have with code correctness, maintenance, extensibility, concurrency, etc. Just don't do it.

Answer 7

I tend to recommend using some sort of DI/IoC container with custom lifetime management instead of singletons (even if you use a "single instance" lifetime manager). At least then it's easy to swap out the implementation to facilitate testing.

Answer 8

If you want the memory saving features of a singleton perhaps you could try the flyweight design pattern?

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

As far as multi-thread issues mentioned above it should be fairly simply with some foresight to implement a lock mechanism for resources that may be shared between threads. http://en.wikipedia.org/wiki/Read/write_lock_pattern

Answer 9

Singletons are a great way to store a shared state in a early prototype.

They are not a silver bullet and come with some problems, but they are a very useful pattern for certain UI/Logic states.

For example in the iOS, you use singletons for getting the [UIApplication sharedApplication], in cocos2d you can use it to get references to certain objects like [CCNotifications sharedManager] and personally I usually start out with a [Game sharedGame] singleton where I can store state that is shared between a lot of different components.

Answer 10

Wow, this is interesting to me, as I've never personally had a problem with the singleton pattern. My current project is a C++ game engine for the Nintendo DS, and I'm implementing a lot of the hardware access utilities (ie. VRAM Banks, Wifi, the two graphics engines) as singleton instances, because they are intended to wrap global C functions in the underlying library.

Answer 11

Only when you have an item that only has one controller but is handled by several modules.

Such as, for example, the mouse interface. Or joystick interface. Or music player. Or sound player. Or the screen. Or the save files manager.

Answer 12

Globals are much faster! So it would fit perfectly for a performance intensive application, like a game.

Singletons are a better global, IMO, and thus the right tool.

Use it sparingly!