Another thing that I have been thinking about is to divide the functionality of the game into several different subsystems. For example the ship movement is one subsystem, the damage calculation is one and the user interface is another. The reason for this is the same as above: flexibility. The game class doesn't need to know which or how many subsystems that are present, more than that it holds them all in an array. It just calls upon them all in turn every frame and lets them do theirs. (It has to make sure though that no duplicate subsystems are present that might interfere whith each other.) This way I am free to add, remove or modify subsystems later on without having to alter the game class. I'm not yet sure how to distribute ingame data between the game class and particular subsystems, though.
The third concept for today is the draw manager, which is a class that is responsible for gathering the graphical output from all the subsystems, sorts it and relays it on to the graphics API abstraction interface, which does the actual drawing. In this way no drawing is done until all subsystems are done updating and as far as graphics are considered the sbsystems can be updated in any order, since they don't do the actual drawing themselves.
Well, I guess that's it for this time. More to come.
BTW: I just realized how much clearer these ideas became to me as I wrote them down. Very nice! [smile]
