Refactoring the engine 2: scene organization
After giving a look to the architecture of the game's renderer, now we'll see how the objects of the game will be organized.
Indexed scene organization
Organizing renderable objects and/or entities in a 3d renderer and a game is a very common problem. In order to move objects, group them and transform them correctly you'll almost always need a hierarchical structure keeping all created objects together: a scene graph. Same thing goes for detecting collisions, deciding what should be rendered and what should not, and so on.
Like any collection of items, the simplest (and less efficient) solution is keeping everything in a linear array. But since objects in a 3d game usually have a position in space, you can create an index on your data: this is called space partitioning and consists in dividing a space region (the whole 3d region where you place your objects) in finite partitions. Since all partitions will be non-overlapping, exploring the space using a spatial index is very efficient.
For instance, the most naive collision detection algorithm loops through all objects and checks if any of them collides with any other object. But using a spatial index, we would be able to only check collisions in the objects of the same subregion (or in adjacent ones), greatly reducing the complexity of the algorithm. For instance, Quad-trees are popular for 2d games or 3d games where objects positions don't vary much on the Y axis (racing games...), while Octrees are great for full 3d games (space-sim or similar). Other interesting trees are kd-trees and R-trees.
My scene manager
After all these good words about how critical it is to use a good scene organization and to implement a good space partitioning algorithm, I have to admit that I'm going to implement the most basic scene manager using a simple list 
... In my case I will be populating the scene with no more than 10 planets and a spaceship: a hierarchical scene manager will be very useful to move planets and their satellites around their orbits, but implementing and debugging a more complex data structure would only cost me precious time right now. Anyway, I'll try to keep it extensible and perhaps implement a working Octree scene manager later on.
SceneManager
This class will keep a reference to the root node of the scene, positioned at {0, 0, 0}. The user will be able to populate his scene by adding new child nodes to the root node and by attaching actors to those nodes. At each frame the SceneManager will recursively visit all actors attached to the scene and trigger their Update() method: for instance the PlayerShip class should process the user's input and update the ship's position and rotation, while a special class - named FakeRotatingActor - could rotate its parent node's position by a constant angle (this is useful for automatically rotating planets around an invisible scene node at the center of their orbit).
After the update, the manager will also recursively explore the scene again and populate the RenderQueue (see article about the rendering subsystem) with the RenderOperation instances created by the actors.
As I said before, this scene manager does not actively organize scene nodes based on their position in space and doesn't expose any method for searching actors or nodes. An eventual Octree implementation could extend the interface, allowing point, nearest-neighbor and range searches.
SceneNode
Each node keeps a list of child nodes and a list of attached Actors. Each node also has a position vector, a scaling value and a rotation quaternion: these values are always relative to the parent node. This means that rotating a scene node means that the same rotation will be passed on to all the node's children. Same goes for scaling and translation.
This dependency on the parent node makes a lot of things easier: for instance when creating a bunch of planets orbiting around the sun, you'll simply have to create a central scene node (child of the sun node) and another (translated) node for each planet. Rotating the central node will also rotate all planets. Of course this scenario won't be very pretty because all planets will rotate by the same angle: you'll have to create a scene node for each planet and rotate them individually. Nonetheless, all satellites of a given planet will rotate correctly, because they will be attached to the planet's node.
Each SceneNode has a WorldTransform property that returns the correct world transformation matrix that should be used to render all child actors of the node. The matrix is computed on demand: all variations of the node's translation, rotation and scale (and variations of all the node's parents!) are cached and then used when the world matrix is actually needed. Since transformation matrices can simply be multiplied together in order to "chain" them, the world transform of each node depends on the one of its parent: in this way all world transforms are computed at most once every frame, while matrices of nodes that did not change (and who are children of nodes that didn't change) will be kept in cache.
Creating a solar system
Since the objective of the XNA contest is to create a solar system, I'll try to compose the scene using the new hierarchical scene manager. This is how it's going to look:
Starting from the root node, the sun will have its own node with several children: each child node represents the "home" node of a planet's orbit and will have attached a so called "FakeRotatingActor". This actor will cause the node and every child to rotate at each frame. Each one of this nodes will have another child node with a non null translation vector: these nodes will represent the effective position of the planets and they will automatically move in space when their parent node rotates.
In a similar way, we can attach other orbit-nodes to the planets and create satellites or rings. All of these elements will rotate and move coherently if any element up in the hierarchy is changed.
