GameComponent.Draw()... why?

GameComponent.Draw()... why?

• vtortola

  Please submit suggestions for improvements/bug reports using XNA Connect. Read this post for details:

  http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=682921&SiteID=1

  
  
  

• Sarath.

  Well, I posted an official suggestion, but, since you asked... I haven't really thought out the implications of my suggestion, and to be honest, I need to look over the GameServices stuff you mentioned. I emphatically dislike the GraphicsComponent being a GameComponent though.
  
  But here are some random thoughts, which are really brainstorming and beyond the scope of my actual suggestion:
  
  Yeah, I think it would make since for GameComponent to include Update(). I think UIComponent would be better named as DrawableComponent and should introduce the Draw method.
  
  I could see the Game having an AddComponent method, and internally it could manage them by type. It could also have an UpdateComponents() method (sort of a FrameUpdate) which could automatically invoke Update() on all GameComponents, and Draw() on the Drawable ones.
  
  I think SubsystemComponents should be restricted to a single instance per type. LogicComponents, while superficially similar, would not be restricted in this way. You could have an AILogicComponent (hypothetically), with a distinct instance for each active entity in a scene, for example... Subsystems couldn't do this.
  
  
  
  
  
  
  

• kuntushi

  I think the design here is so that you can create or use other types of components that need to be graphical as well.
  
  For example, somewhere I saw mention of a Framerate component from MS that you can just drop in to have the framerate displayed.
  
  If the GameComponent class didn't provide a defined place to do drawing each component would need to come up with its own way of doing it and knowing *when* to do it. By defining the place to do it, components that want to make use of it can, those that don't, well, don't.
  
  While not an official response, I hope it answers your question.
  
  Cheers,
  
  James
  
  
  

• angelina

  But perhaps its a good idea to keep the Draw() method for debugging purposes... ex. drawing bounding volumes, forces, contact points, paths, and a lot of stuff that is not drawn in the final release and would need some more and confusing code to draw them if they don't implement Draw()
  
  
  

• pankajsparashar

  Hey, Amadrias....
  
  A SceneGraph, in my imagined perfect world, would be implemented as a DrawableComponent. And if you look at my elaboration, all GameComponents DO have an Update() method, but only DrawableComponents have a Draw() method.
  
  

• DigitalFusion

  Hi Dave,

  How would you see the current GameComponent changing Would UIComponent introduce Draw() What would GameComponent look like. You're correct in that the "looseness" of the structure provided by the GameComponent encourages them to be "system like" components. We're trying to figure out how far to go here in v1. On one extreme you have what is in the beta and on the other you have something more policy-laden like WinForms Control or something. Somewhere in-between might be interesting (or more specifically, what is GameComponent now is really your SubsystemComponent (or maybe your UIComponent, not sure)).

  Note that "system like" things are probably more services (Game.GameServices) which are available as a mechanism for components to publish/subscribe to centralized services (c.f. IGraphicsDeviceService). Services are different from GameComponents in that services are disconnected from the update/draw mechanism.

  We're really interested in feedback here. We want to know what people want to see in a game component infrastructure.

  
  
  

• autistic_clown

  From my perspective every single GameComponent should have an Update method that will help handling any changes in one frame.
  
  The rendering of content should be handled by the SceneGraph. I once bought an Australian Game Engine made by the makers of Trainz: Auran Jet. Their OO design was just perfect for games development, I never found any other game engine design using OOP that would provide all the inheritance advantages while preserving the logic of a game engine.
  
  I think you may find some interesting ideas on it. If I remember well, they have on their website a demo with source (the engine is quite old now on the rendering part but the rest is just wonderful).
  
  For new game developers, be careful, Auran Jet was a C++ game engine.
  
  

• Elad ga

  I like Dave's idea as well.  A good example of a component that doesn't need a "Draw" method would be a PhysicsComponent of some sort.  It just needs to be updated and doesn't care about all the drawing stuff.
  
  

• wendling lionel

  I'll definately submit that, thanks.
  
  

• SteveMargetts

  Jeff Weber wrote:

  I like Dave's idea as well. A good example of a component that doesn't need a "Draw" method would be a PhysicsComponent of some sort. It just needs to be updated and doesn't care about all the drawing stuff.

  
  
  Yeah. Physics could even be implemented as a PhysicsSubsystemComponent (meaning there is only one instance), and individual entities could have something like a PhysicsEntityComponent : LogicComponent, which would update and reconcile the entity's information with the PhysicsSubsystemComponent.
  
  I think having these subclasses would enforce good design without taking any flexibility from the developer.
  
  

• Richard_Wolf

  The concern (which is a bit dramatic... it's more of a suggestion) is a design issue. If GameComponents are to be reusable elements such as debug output and things like that, then they shouldn't be equal (hierarchically speaking) to the GraphicsComponent which renders them.
  
  It also seems that any given component should either be drawn, or not be drawn. If it is not drawn, it probably should not have a Draw method. That's why it would be a good idea to make the distinction with seperate abstract classes, DrawableComponent and LogicComponent.
  
  Note that a LogicComponent could provide it's own Draw method and draw itself in those rare cases where bad design leads one to need such a method.
  
  

• Boreholes_to_Bottom_Lines

  OK. I read on some other threads that GameComponent is meant to be used for reusable UI elements, and other things like that. This is nice and all, but considering the fact that GraphicsComponent is nothing of the sort and is actually representative of a game subsystem I think it is a bit of an awkward design.
  
  So, unless I am misunderstanding something, I have a suggestion for the XNA dev team if they are interested in suggestions.
  
  It might be a good idea to refine the whole "component" idea a bit. Of course, it is possible to go overboard, but I think that having GraphicsComponent on the same level as display elements is strange. I think a generic but well-defined taxonomy of Components would be nice:
  
  GameComponent --> SubsystemComponent --> GraphicsComponent (supplied with framework), NetworkComponent, InputComponent, etc...
  
  GameComponent --> UIComponent --> HUD, Scoreboard, PIP, whatever...
  
  GameComponent --> LogicComponent --> WorldEnvironment (day night, temperature, whatever)...
  
  
  Just an idea.
  
  

• NetPochi

  Is the concern with Draw on GameComponent performance or some semantic issue Certainly you can make GameComponents that don't override Draw. :)

  
  
  

• JesseD70

  I'll second Dave in that I find GameComponent somewhat ambiguous. I'll post some comments as soon as I dig a little deeper into the Services and formulate a more educated opinion.
  
• GameComponent.Draw()... why?