Correct usage of Game.GameServices.GetService(<T>) method
Hi there,
This is my first post on these boards so I'd like to say hello in the first place.
Few days ago I started to look into XNA. I have some expierence with MDX1.1.
Now I started working on a Tetris clone. To get a grasp of how the XNA teams considers that we develop games, I decided to split the game into 2 projects. The game itself and a Framework kind of Project. The framework includes classes for GameState, GameStateManagement, InputHandler etc...
The Tetris Blocks in the game are currently GameComponents. My BaseGameState class inherits XNA.Game. Every GameState currently has its own collection of GameComponents which gets Drawn in the currently active GameState's Draw function.
Also, my Entry point for the game instantiaties an instance of my Framework and passes it to the different GameStates, which in turns passes it if needed to the GameComponents etc...
Now I was wondering: Wouldn't it be more XNA like if my Framework implemented an IFrameworkService interface which I could then retrieve using the GameServices.GetService<IFrameworkService> method anywhere I want? I guess that would be more like XNA is designed to be used.
Or should I even go to the point to implement a different IService interface for every part of the Framework like IInputHandlerService, IGameStateManagerService etc... ?
Or am I totally wrong here and those should all be GameComponents? I personally don't think so. As those are methods, properties which should be available throughout the game it would be wiser to add them to the GameServices collection?
What do you think. I'm not sure I completely understand how the XNA team considered all this to be used. Mind you I could do it like before in MDX. That wouldn't be a problem. It's just that I want to get an idea of how the design could benefit from the patterns that XNA provides
[1919 byte] By [
RizMan] at [2007-12-25]
I confess to still being confused about when to use GameComponents and when to go the services route. Tonight I cobbled together an InputController GameComponent, and that "felt" to be the right usage/application of a GameComponent to me.
I still have to pass a Game reference to my menu class because it's just a regular C# class, and I need the reference to get the controller. But apart from that it works nicely and I can see the potential. I expect the next step needs to be an advanced menu GameComponent, where you can feed it pages, sprites for graphical data, define the routing between buttons and pages etc. But that's more than I want to undertake at the moment.
Ok. So I'm gonna try the following:
The Framework Class will implement both GameComponent and IFrameworkService. The InputHandler, GameStateManager etc... will be updated in the Framework.Update() method.
An instance of Framework will be created at the Game's startup and added to GameComponents collection. Thus without a lot of code, everything in the Framework will automatically be updated due to the GameComponents mechanism and I will be able to access the Framework from any place in the code using the GetService<> method.
 DialogPimp wrote: |
| I still have to pass a Game reference to my menu class because it's just a regular C# class, and I need the reference to get the controller. |
|
It doesn't matter that it's a regular C# class. That's what the GameServices collection is for. Have the InputController implement an InputControllerService and you can get to it by doing:
IInputControllerService ics = Game.GameServices.GetService(IInputControllerService);
ControllerData data = ics.ControllerData; //or whatever you want to expose through the service
You avoid passing references around. I implemented a service for my GameLevel class in about 5 minutes so objects could get to the level data without having to do a hack. Very useful.
I hear what you're saying Jim, but my regular class still needs to
know about my Game instance, before I can access any services or components.
I think I'm getting too hung up on this - a quick check of the Spacewar code shows that the Game is passed through on the constructor of the Screen objects, for example.
