Well, in the latest version we already split the physics from the rendering completely by splitting the whole engine. I'm not really sure what else you mean with "framerate scalibility in pygame" (note that the server won't even use pygame).
Hooray for modularity
I didn't check how/where you made the split so this might be totally redundand, but I always thought it would be a good idea to have a set of "gameplay domain" classes which use and manipulate a limited set of information (the essential part of the game state) and send/receive events. For example, a gameplay "Character" class would update the x and y positions and speeds in each step, react to collisions etc. but would not contain any code for drawing, sounds, particle effects or other things from the "display domain" (my am I using many quotes today), it would only be concerned with the gameplay domain. Those would be the classes used e.g. by a dedicated server to simulate the game state, and by the networking code which would have to transfer the events and keep the state data in sync.
Then, for clients, you would have an extra set of "display domain" classes which only handle the drawing, sound and eyecandy by extending / decorating the gameplay classes. For example, a display Character class could be an extension of the gameplay Character class and react to a Death event by playing a death sound (and then passing the event on to the base class of course).
Author
Topic: Official PyGG2 Development thread (Read 161430 times)
