Questions regarding games architecture with XNA

So I've finally got around to playing around with XNA and have been toying around with making a 2D game (I have a bunch of art assets from a friend who developed it on iOS)

A lot of things seem to be easy to do and come out of the box however I'm left stumped for a bunch of stuff since most of the literature (the books I bought for instance) don't pay too much attention to 2D.

I'd really appreciate any clarification or being pointed to more information on the following questins:

1. What is the point of a Game Service? I understand the whole idiom of registering an object as a service so that any other GameComponent can grab it, however how does this beat out simply making it perhaps public or static? For instance, my book recommended registering the SpriteBatch object in the Game.cs class. I'm not sure how this is preferrable to simply making it public/static since there should only be one instance of Game anyways (singleton)?

2. I'm confused on when I should inherit from GameComponent or RenderableGameComponent. I'm trying to follow a Manager/Controller design, such that all entities are created/owned by a single manager and the same for other things. I currently have each Manager/Controller inherit from GameComponent, however how does this beat out having the Game object own all the Managers and manually call update on them and draw ?

3. I noticed that Initialize is called before ContentLoad(), I found this annoying since in my Initialize is where I'd like to create some of my entities (i.e. Sprite, Player etc..), however I can't give them their loaded SpriteSheets or Textures since the call to load them hasn't occurred yet. Am I perhaps initializing incorrectly or do people just assign the texture further down in ContentLoad?

Those seem to be my biggest "WTF" of not really understanding

The answer to your question is simply: Do whatever works. Ideally do what is simple and works. Often using the built-in architecture is not simple because, as you are finding, you have to jump through hoops to structure your game the way you want.

To answer question one, I will refer you to my answer to the question "Why use services?". The short answer is that services are a good way to avoid coupling (versioning, dependency, extensibility) issues that you will never encounter in a self-contained game. Most of the time it's simpler to just make a member public (and perhaps even static, if you're in a hurry) and worry about more interesting problems.

To answer your second question, I will refer you to my answer to the question "What are the cons of using DrawableGameComponent for every instance of a game object?" as well as my thoughts on game architecture. The short answer is: there is no benefit to using the GameComponent over simply creating your own classes and calling methods like Draw and Update yourself. If GameComponent matches your desired architecture exactly, by all means use it - but almost always it doesn't.

Using services and components only really becomes interesting if you're building a library for third-party consumption. XNA itself does this - it has IGraphicsDeviceService and GamerServicesComponent, for example. These fulfil specific decoupling requirements that you typically don't encounter when developing a game.

Finally, the answer to your third question is quite simple: Just create your game entities in LoadContent. There is nothing particularly special about Initialize.

It's worth pointing out that the entire Microsoft.Xna.Framework.Game assembly is optional. It provides an extremely useful starting point - but it should by no means be considered as "the one right way" to do things.

• Very interesting way to see it. Much more realistic and down to earth than my answer. Well deserved +1, sir. – Jesse Emond Sep 2 '11 at 3:11
• I have one more question! What about the origin when you draw for a Texture2D. Is it common to place the origin in the bottom middle of the texture? I'm trying to do animations, and I'm finding having the origin at (0,0) is causing the texture to shift slightly if the width and height aren't the same – Setheron Sep 2 '11 at 3:39
• @Setheron: You should really create a new question - as this is quite unrelated to the original question. I'm going to revert the edit you made to this question. The origin for SpriteBatch.Draw is specified in texture-pixel coordinates relative to the top-left of the texture (or source rectangle, if you use one). – Andrew Russell Sep 2 '11 at 5:11
• @Andrew: I recently refactored my game so that it was entirely based on services instead of public/static properties. Why? Testability. It's near impossible to switch things out with the property approach, whereas it's trivial if everything is initialised with a IServiceProvider that can be stuffed with anything the class needs by your testing method. It also avoids the need to instantiate the Game object itself in your test, which gets messy very quickly. – Matthew Scharley Sep 2 '11 at 9:07
• As an aside, I still have lots of public properties on the Game object. They just happen to be accessed via interfaces that get pushed into Game.Services which then gets passed around to everything to get what they need out of again. – Matthew Scharley Sep 2 '11 at 9:10

For your first question, I must admit that I don't really know the actual answer. I guess it would be for the same reason as to why singleton is generally a bad design pattern. I'll refer you to a quote from this link:

The first one we thought of (and one of the reasons behind introducing services) was making a GraphicsDevice reference available across a game.Originally we had the Game own the GraphicsDevice and expose it via a property like Game.GraphicsDevice. The problem with this was that this tightly bound the GraphicsDevice to the Game, not allowing someone else to “own” the device (such as a renderer) and preventing someone from using a future updated GraphicsDevice without shipping a new version of Game that wouldn’t be backwards compatible.

For your second question, I'd assume using Components like this would be more useful if you would be following a component-based approach instead, as if you would have a list of Sprite components that would know how to draw and update themselves instead of a manager that knows how to update and draw every sprite. I agree, it sounds the same but I prefer a component-based design because I really like the object-oriented approach it has.

For your third question, yes you should load any form of content (assets, fonts, etc.) in the LoadContent method. As for the initialization, you would usually create the Player object within the Initialize function and then load its content within LoadContent.. Or you can just do it all within LoadContent if you wish.