[ad133]

Game dev is different than back-end server dev, is different from front-end web or desktop dev.

For example, in back-end Java dev, I never use singleton objects in the truest sense of the pattern; singletons cannot be mocked out to test units in isolation. Instead, instantiate it with a dependency injection container and let your framework (Guice, Spring) wire things together. In effect, your global state becomes contained within a single context. Nothing stopping you having two contexts in the same runtime environment though.

I find static methods are okay if they are concise and have no state; in particular if I'd never want to test the caller without it making the call to the static method anyway. This is becoming more important with Java 8's lambdas and needing to write helper methods.

On the other hand, the cost of doing this might not be worthwhile for a game dev? Do game devs write unit tests? I have no idea.

[virtualized]

Game developers don't write tests. They pick up habits along the way and keep them for a long time. The code might be crap, but they know their crap very well and can debug it. There is less need for tests because most code never rarely refactored or being touched at all. It's already in the familiar style, why change anything?