What's the difference between XNA Game Services and glorified global variables?

Question

The Microsoft.Xna.Framework.Game class has a Services property that allows the programmer to add a service to their game by providing the type of the class and an instance of the class to the Add method.

Now, instead of having to pass an AudioComponent to all classes and methods that require it, instead you just pass your Game instance and look up the service. (Service Locator)

Now, because games have many services (GraphicsDevice, SceneGraph, AudioComponent, EffectsManager, et cetera), you will now basically be passing Game to everything.

So why not just make these instances a Singleton? Well, because Singletons are bad because they have a global state, prevent testing, and make your design much more brittle. Service locators are equally considered to be an anti-pattern to many because instead of just passing the dependency to an object, you pass a service locator (the Game) which couples that class with the rest of the services.

So then why are Services recommended in XNA and game development? Is it because games are different from regular programs and are highly intertwined with their components and having to pass every component necessary for the functioning of a class would be highly cumbersome? Are Game Services just then a necessary evil in game design? Are there alternatives that don't involve lengthy parameter lists and coupling?

Answer 1

I don't think everyone agrees that service locators are bad. Service Locators provide a way to decouple important functionality that everyone needs from their actual implementation. Service locators also provide a way to swap services at run time. Also I don't think it's true that you need to pass around the service locator around everywhere. I think you can access it from everywhere. While a game class with globals would need to be passed around a thousand times per frame (which would cause bad performance).

To make the difference between the service locator and an class with globals a bit more clear consider the following example:

I'm making a game and use a gameA class object that has a global variable: the content loader. Now in my next game I don't want to use the gameA class but create a new gameB class. I now have to again add the globals of gameA to gameB which is extra work. Also it becomes hard to configure the type of content loader I want. Say I have a game that runs both on the PC and on the XBOX. On the PC I want a content loader that can also open a 'open file' dialog. While on the XBOX I definately don't want this. By having a config file I can even halfway trough the game easily change the content loader, even from somewhere else than the gameA class, without just making the globals in gameA all public.

Now consider I'm using a service locator. I can always keep using it. And even what kind of services are there can be different all the time. It is also true that I won't even care about their implementation as long as they have a common interface. (Although I could use that in a gamA like class aswell).

Anyway I think you will find the game services pretty handy. Everyone I know uses it. To help you out a bit more. I've created a small helper class around game services so that you can do quite a bit less casting all the time: http://roy-t.nl/index.php/2010/08/25/xna-accessing-contentmanager-and-graphicsdevice-anywhere-anytime-the-gameservicecontainer/ I use it quite a lot.

Answer 2

So why not just make these instances a Singleton? Well, because Singletons are bad because they have a global state, prevent testing, and make your design much more brittle.

Singletons generally take a lot of useful traits and package them together in an awful hybrid that gives you several things you don't want along with whichever bit you did want. (Was it 'create-on-demand' characteristics? Global scope? Enforcement of at least one instance? Prohibition of multiple instances?)

Service locators are equally considered to be an anti-pattern to many because instead of just passing the dependency to an object, you pass a service locator (the Game) which couples that class with the rest of the services.

You can't avoid coupling entirely. Things use other things and without that your program does nothing. So the only real question is what level of abstraction it's at.

Most texts on object orientation make a distinction between Composition and Aggregation. It's important to know the conceptual difference between something that you own and something that you know about. Unfortunately most modern languages don't have a clear distinction here, and a reference to an object could mean either of these things. (Ironically, C++ does a better job, if you use the various smart pointer types.)

One way in which you can make composition and aggregation clear in your code is by using services for aggregated objects. Services are one way to provide access to stuff you don't own, but which you can use.

So then why are Services recommended in XNA and game development?

I don't think they are universally recommended in game development.