For example, if I create a GameComponent to manage input, I wouldn't want it to collect input at the end of Game.UpdateComponents, because it would be another tick before the entities used the input that was collected. I would want it to update near the front of the Game.UpdateComponents loop. Is there any way to ensure update order?
just swap things around in the code that adds them to your game to
control this.
This concept of update order is something I've been thinking about too. I can see situations where components need to be updated/drawn before the user code and situations where then need to be done after user code. There could also be situations where components need to be updated first but drawn last.
Perhaps components that have complex needs regarding when they are updated should use another method, instead of Update(). In your input case you could have a method GatherInput() that you ask the user to call before updating other components.
It's quite a tricky problem and I'd be very interested in hearing what others have to say about it.
Cheers,
Leaf.
Edit: Note to self. Must type faster, threads keep ending before I've finished my post :)
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
Seems pretty dangerous to me...
It would be nice to have a way of managing component update/draw order without violating this warning.
Thats the reason i dont think im going to use the component pattern much. Having an easy way of specifying ordering and changing it later on is very important IMO.
I normally base my game loop around one or more ordered list of delegates. Game components hook onto updates on a list with a specific ordering value. If ordering values are defined as enums its very easy to change ordering of groups of components and interleave new updates.
For every game project I've worked on so far I've put my game objects (or components if you will) in a list that gets updated and rendered automatically. This holds only for objects in that list that were not updated / rendered earlier during the current frame (consider using a time stamp or frame id). For specific dependencies between game objects I allow myself to do dedicated update calls in specialised game object code, i.e. object A has to be updated before object B, then in the function body of object B there's something like a.Update( elapsedTime ). Mind you that the Update implementation in the base class checks whether the update hasn't already taken place during the current frame. This way you it's certain that all objects are updated exactly one time per frame, while maintaining full flexilibity in dependency control. The same goes for rendering.
Now in this case, considering GameComponents, I'm contemplating the thought of deriving my own GameComponent which follows this pattern.
Any other thoughts on this?
DodgingRain wrote:
Is there an "official" way of dealing with the order of components? Changing the order they were added is kinda cheesy and doesn't work that well if you want to change the z order of images at run time.
Lets pretend you are sorting a list of 2D Components. Create a base class of type GameComponent and add an integer member to represent the z value. Add a public property to get and set the z value. Now make all your new components derive from this base class. Each component can now have a z value assigned to it. (I was smoking crack or something when I thought this part up, see below --> If you iterate through the GameComponent list in your game object, you can typecast the reference to your GameComponent base class type and retrieve the Z value for each individual game component. If you get a little more creative, we can now apply a sorting algorithm to sort the list based on the return Z value. This would be the quickest and dirtiest way to achieve the effect you are looking for.)
- Bill
[Edit]
Well partially scratch that, I didn't notice this piece of code:
this.GameComponents.Add(this.graphics);
and the fact that the graphics object is in fact an GameComponent itself. Maybe create an base class containing the Z value as mentioned above and a static list containing all of the sprites. You will sort the static list in the game's update method by each sprites z value. Next clear the entire GameComponent list and re-add the graphics object to the front of the list (And any other non sprite GameComponents). Afterwhich iterate through the static list sorting the sprites. Finally add each sprite back to the GameComponent list. If your slick enough, you may be able to sort the list while adding the sprites back to the GameComponent list to optimize things.
I may change my mind on this again. I need a good nites sleep to think things over. But you get the idea......
[/edit]
My normal method has been to have a rendering class that contains an array of my sprites. The rendering class has a resort method that resorts the sprites based on z order and then the sprites are rendered in array order. That way I don't suffer from the overhead of verifying the sort every game loop.
I'm just suprised that they didn't build this into the components since it's a must have feature both from a rendering as well as a logic standpoint.
