|
XNA provides a neat little system for you to organize your
game's different parts in: GameComponents.
You can use them to modularize your game's subsystems,
eg. have a GuiComponent, PhysicsComponent,
SceneGraphComponent etc. so you avoid having all that
code in your Game class, or can use them for your actual
game objects in smaller games.
However, the GameComponent and
DrawableGameComponent classes provided
by XNA force you to reference the Game
class. This is unfortunate if you want to use those components
in a WinForms-based XNA application and gets in the way
when you try to write unit tests for your components because
now you have to create a dummy Game
instance as well (and better hope that component won't
go shopping for references in the Game's
Components and Services
collections as well).
Luckily, the GameComponentCollection
used by XNA to store your components manages
IGameComponents
and updating/drawing are based on the IUpdateable
and IDrawable
interfaces alone, so there's nothing preventing you from rolling your
own components without referencing the Game class.
That's exactly what I did when I started writing an editor for
my Island War game. I simply reimplemented XNA's
GameComponent and
DrawableGameComponent classes, minus
the Game reference. I named them
Component and DrawableComponent
(cleverly removing the 'Game' from the name to show that these
no longer reference the Game class):
Users of my components (like my GUI and particle system classes)
wouldn't notice any difference and could use the classes like
normal GameComponents, but the custom base
class allowed me to use this components in a WinForms environment.
Lately, I've been tinkering around with SunBurn,
Synapse Gaming's
lighting and rendering framework for XNA. Here you have drawable
things that do not access the GraphicsDevice.
Instead, they will modify SunBurn's scene graph. Thus, carrying
around the GraphicsDevice reference in my
DrawableComponent became essentially dead weight
for the components involved.
So I decided to make a variant of my
DrawableComponent that would still do all of
the uninteresting stuff managing the Visible and
DrawOrder properties, firing events and so on,
but not handle the GraphicsDevice for me. What
I ended up with is this:
In retrospect, this turns out to be a much cleaner design, too:
The DrawableComponent only handles the
implementation of the IDrawable interface instead
of doing both that and managging the GraphicsDevice.
And the GraphicsDeviceDrawableComponent
(excuse the long name, haven't found anything more concise yet),
deriving from DrawableComponent, only handles
the management of the GraphicsDevice.
This will be a breaking change in the next Nuclex Framework
release, but all you have to do is paste
"GraphicsDevice" in front of your
"DrawableComponent". I think this is
nicer than having some
DrawableComponentWithoutGraphicsDevice class :).
I'd wager that in larger games (which is what my Nuclex Framework
is designed for) a scene graph or something comparable is probably
used in the majority of cases and direct GraphicsDevice
access only happens in some corner cases.
|
Comments
Can you please post three code examples for the three diagrams for better understanding?
Thanks.
Because that would mean duplicating a lot of code (see en.wikipedia.org/wiki/Don't_repeat_yourself).
I also prefer small classes and this would add a lot of noise to each of them, making them less readable. My average class has ~150 lines of code.
Finally, in a "class Enemy" I'd expect to find the code that controls the behavior of an enemy - instead it would also be responsible for the game component handling (en.wikipedia.org/wiki/Single_responsibility_principle).
To deal with content loading and any kind of external dependencies, I use services (eg. IContentService, ICameraService) passed to the constructors of my components. One could also use the Game.Services container as I did earlier
(http://www.nuclex.org/articles/architecture/6-game-components-and-game-services), but I am sold on dependency injection now :)
In my current project (an RTS game), I separate logic from drawing by splitting all game entities into three parts. For a flak turret, for example, I'd have these classes:
I guess it wouldn't hurt to merge the behavior class into the turret itself, but by externalizing I avoid having the FlakTurret class store a reference back to its parent (the World class).
Unfortunately when I start coding, I hit a brick wall. For example where do you setup the injection? What about FlakTurretBehav ior class - how does it find out the places of enemies and projectiles? About TurretRenderer - where does it get the instance of a model...
Sorry for so many questions, but my project is sooo tightly coupled (i.e. I pass Game, GraphicsDevice and an intance of my "GameWorld" everywhere), that I cannot add or change anything anymore. I am trying to rewrite it - but don't know where to start.
The way I try to avoid this is to keep looking for indications that the design is turning sour. For example, having parent references (eg. world has buildings, buildings have reference back to world) is usually an indication for coupling getting too tight. Especially if the parent class would allow the child to access a whole object graph (eg. to do stuff like Parent.Players[0].Units.FindAirborne().DestroyAll() - tight-coupling the building with the world, player, unitmanager and unitcollection classes in one go :P).
Another indication I use is when a class consumes too many categorically different references. If my building renderer consumes the scene graph, camera and content manager, that's okay - they're all rendering-related and necessary. If I have more than 2 such references, I usually construct either a reference container (see http://www.nuclex.org/blog/gamedev/109-code-better-reference-containers-for-change-resistant-constructors) or I consolidate functionality - for example by adding a ISceneManager.Camera property - the camera can still be represented by a different service, but it's now packaged under the scene manager. Of course the latter approach should be used with care as it introduces artifical service dependencies.
If, on the other hand, a class consumes 3+ references of different categories (say, input manager, world state and graphics device service), that's a clear indication that the class is having too many responsibilitie s and should be split. Knowing where to split and what to turn into an interface is a science of itself. I haven't yet been able to extract the rules I work by there :)
I wish I knew a formalized approach that I could simply follow, but I'm beginning to doubt there is such a thing. What I do now is to try and look at the whole problem, brainstorming different approaches with their consequences (I believe, like a good chess player, the more experience one has, the deeper one can follow this "search tree" and the earlier one can tell when a "move" isn't worth following down the tree). But I've messed up often enough. Luckily, it was mostly before I started using XNA, so one noticed because I kept my earlier code to myself most of the time XD
RSS feed for comments to this post