Scene isnt really a sprite because it doesnt contain image data in itself...
How i think you should do it unless you find a better solution:
*Linear container of sprites (so sprites have child sprites)
*Linear container of stuff affecting the rendering (image?)
*Linear container of stuff that needs to get input (button)
(you might not need a linear container, which is like vector or similiar, for all of those, or you might put the images and buttons in the same, whichever works the best)
*Cannot have sprites or other buttons or images as children
So you get a tree like
Which you store the root node for in a Scene object. The scene object can give you methods and such which modify the whole tree or get you data about it or possibly handle the allocation and building of it.
I believe this is called a scene-graph or is similiar to it.
Because the sprites dont in this way need to contain an image, i wouldnt call them sprites but find a better name for them.
If you make a rule that a sprite may not go outside the edges of its parent or get input from there, you can do rendering hierarchially, and input in the same way (for each sprite, check wether the mouse is on top, and if yes, do the same for its children. If the sprite is a button you can pass input information depeding on rules you make like allowing input to sprites covered by other sprites etc.)
I put the rendering affecting components in a different container than others in the example because that way when rendering you can get all of those components of the sprite, and for each call something like .Draw(spriteItsContainedIn) to draw the image or text on it...
might be better, where the tree is a tree of objectcontainers, and sprite has an image property/component
I believe this is called or is similiar to a SceneGraph and might have something to do with component based design (or whatever the term is)
Edited by Waterlimon, 24 October 2012 - 07:28 AM.