Take a few steps back, willya?philippeqc wrote: Sorta kindish yeah.
For sure not any world structure. Not even the empire. (1)
Either is the game (the object) or the game (the application, some kind of static thingy).
But cameras are called often to re-display the scene at every increment of all the status. So they should be easily accessible from there.
yes, but the cycle has a pos and the cam has pos. But what grid gets picked?
Ignore all the other objects except for the player. The player's eyes own the camera. Think about that for a sec. If the player's eyes own the camera, that means the camera needs to be able to point where the eyes want to look. The eyes may want to look anywhere, either hover a few feet above the cycle, watch from inside the cycle, or even surf from grid to grid to see what's going on.
So the camera needs knowledge of the grid the player wants to watch, but that's all it needs. It doesn't need to be owned by the grid in order for it to have knowledge of the grid. Presumably the camera also needs to have knowledge of the master server list (or at least what it looks like) and the various menus that exist for manipulating settings and so forth.
Now, if I were writing this from scratch, I would tend to make the camera exist independently of everything else. I would give it a member variable that it would use to figure out where the other objects in the grid were. In that case, inheritance is the wrong solution for this problem. It doesn't make sense for the camera to keep track of player positions, walls, lengths, speeds, and so forth. The cameras only job is to take a whole bunch of snapshots every second and give it up to the renderer. So something else needs to track that stuff, say the grid, or Arena, or coliseum, or empire. Something else, anything else. And that something doesn't give a rat's ass where the cameras are either. So there's no master/slave relationship here, no ownership is within the relationship.
So, you could use a static member, but that doesn't very well account for variable numbers of cameras. You could use a global dynamic array (call it gList or something?). In fact, STL might well have the right solution for where to store the cameras. How to access them? It seems to me that the only components of the program that need knowledge of the cameras are the renderer and the grid-picker. The render needs to read from the camera, and the grid-picker needs to write to the camera. The cameras need knowledge of the grid being watched, and they'll read from the grid. The grid will be written to from elsewhere in the program. You could have main() create the Empire object and then pass it to the camera in the camera's constructor, or rather whenever it's time to construct the camera pass it the Empire. Or something like that. that sort of interface can get pretty hairy to maintain if it's done even slightly wrong.
How to implement it? Beats me. I'm just an armchair programmer. (well, not really, but until I actually have time to hack on this thing, that's what I am)