Do retail games use “inversion of control” and “dependency injection”?

Question

Many of the more diligent software developers I know are moving to inversion of control and dependency injection to handle references to objects. Coming from a Flash games perspective I don't know all the ins and outs of AAA studios, so: are these used in the retail game world?

Answer 1

You call it 'diligent software development', I call it 'painful overengineering'. That's not to say that inversion of control is bad - in fact, the basic definition of it is good - but the proliferation of entire frameworks and methods of working to achieve all this is little short of insane, especially combined with the way people are trashing perfectly good and clean interfaces in order to be able to inject interchangeable components that 99% of the time you'll never interchange. It's the sort of thing that could only originate from the Java enterprise environment and I'm glad it doesn't have as much of a foothold elsewhere.

Often the argument is that even if you don't interchange components, you want to be able to test them in isolation with mock objects and the like. However, I'm afraid I will never buy the argument that it's worth bloating and complicating an interface in order to be better able to test it. Testing proves one thing only - that your tests work. Clean and minimal interfaces on the other hand go a long way towards proving that your code works.

So, the short answer: yes, but not in the way you're thinking. Sometimes, when you need interchangeable behaviour, you'll pass in an object to a constructor that dictates part of the new object's behaviour. That's about it.

Answer 2

Not in my experience. Which is a shame, as games code needs to be very adaptable, and these approaches would definitely help.

However it must be said that both methods could, in C++, introduce virtual tables where there were none before, bringing with them an appropriate performance hit.

Answer 3

I would say that it is one tool among many, and it is used on occasion. As tenpn said any method that introduces vtables (and generally any extra indirection) can have a performance penalty, but this is something that we should only worry about for low-level code. For high-level structural code that isn't really an issue, and IoC can have positive benefits. Anything to reduce dependencies between classes and make your code more flexible.

Answer 4

Strategy Pattern, Composition, Dependency Injection, are all very closely related.

Since the Strategy Pattern is a form of Dependency Injection, if you take a look at engines like Unity for example they are completely based off this principle. Their use of Components(Strategy Pattern) is deeply embedded into their whole engine.

One of the main benefits aside from reuse of components is to avoid the dreaded deep class hierarchies.

Here is an article by Mick West who talks about how he introduced this type of system into the Tony Hawk series of games by Neversoft.

Evolve Your Hierarchy

Up until fairly recent years, game programmers have consistently used a deep class hierarchy to represent game entities. The tide is beginning to shift from this use of deep hierarchies to a variety of methods that compose a game entity object as an aggregation of components...

Answer 5

Gotta agree with Kylotan on this one. "Dependency injection" is an ugly Java solution to an ugly Java conceptual flaw, and the only reason anyone's looking at it in other languages at all is because Java's becoming a first language for a lot of people, when it really shouldn't.

Inversion of control, on the other hand, is a useful idea that's been around for a long time, and is very helpful when done right. (Not the Java/Dependency Injection way.) In fact, you probably do it all the time if you're working in a sane programming language. When I first read up on this whole "IOC" thing everyone was buzzing about, I was completely underwhelmed. Inversion of Control is nothing more than passing a function pointer (or method pointer) to a routine or object in order to help customize its behavior.

This is an idea that's been around since the 1950s. It's in the C standard library (qsort comes to mind) and it's all over the place in Delphi and .NET (event handlers/delegates). It enables old code to call new code without needing to recompile the old code, and it gets used all the time in game engines.

Answer 6

There seems to be a lot of confusion about the Inversion of Control (IoC) pattern. A number of people have equated it with the Strategy Pattern or a Component Model, but these comparison don't really capture what IoC is about. IoC is really about how a dependency is obtained. Let me give you an example:

class Game {
    void Load() {
        this.Sprite.Load(); // loads resource for drawing later
    }
}

class Sprite {
    void Load() {
        FileReader reader = new FileReader("path/to/resource.gif");
        // load image from file
    }
}

In the above it's clear that Sprite.Load has a dependency on a FileReader. When you want to test the method you need the following:

1. A file system in place
2. A test file to load from the file system
3. Ability to trigger common file system errors

The first two are obvious, but if you want to ensure that your error handling works as expected you really need #3, too. In both cases you've potentially slowed your tests down quite a bit as they now need to go to disk and you've likely made your testing environment more complicated.

The goal of IoC is to decouple the use of behavior from its construction. Note how this differs from the Strategy pattern. With the Strategy pattern the goal is to encapsulate a re-usuable chunk of behavior so that you can easily extend it in the future; it has nothing to say about how strategies are constructed.

If we were to rewrite the Sprite.Load method above we would likely end up with:

class Sprite {
    void Load(IReader reader) {
        // load image through reader
    }
}

Now, we have decoupled the construction of the reader from its use. Therefore, it's possible to swap in a test reader during testing. This means that your testing environment no longer needs a file system, test files, and can easily simulate error events.

Note that I did two things in my rewrite. I created an interface IReader which encapsulated some behavior -- i.e. implemented the Strategy pattern. In addition, I moved the responsibility for creating the right reader to another class.

Maybe we don't need a new pattern name to describe the above. It strikes me as a mix of the Strategy and Factory patterns (for IoC containers). That being said, I'm not sure on what grounds people are objecting to this pattern as it's clear that it solves a real problem, and, certainly, it's not obvious to me what this has to do with Java.

Answer 7

I'm not a professionnal game dev, and only tried implementing IoC in C++ once, so this is just speculating.

However, I suspect game developers's would be suspicious about IoC because it means :

1/ designing lots of interfaces and lots of small classes

2/ having pretty much every function call being lately bound

Now, it might be a coincidence, but both tend to be a little bit more complicated and/or problematic for performances in C++ (which is widely used in game, isn't it ?) than in Java , where IoC became widespread (Probably because it was relatively easy to do, help people design saner object hierarchies, and because some believed it could turn writing an a application in Java into writing an application in XML, but that's another debate :P)

I'm interested in the comments if that does not make any sense at all ;)