Kris Schnee wrote:
The idea is that instead of calling a shop screen from a walking-around screen, which risks having you get into some tangled recursion, the program "drops" from the walking screen back to the main loop, with a state variable saying "the next screen to go to is the shop screen."
This sounds similar to the way I've organised a couple of my recent PyGame entries. I have a Shell object at the top which implements the main loop. The Shell has an instance variable called current_screen which at any moment points to one of a number of different Screen subclasses which present different user interfaces. The Screen objects have methods for drawing the display, handling input events, etc. All the Screen objects hold a reference to a single Game object which contains all of the game state (the "model" in MVC terminology). +-------------+ +----------+ | | | | | Screen1 |------->| | | | | | +------------------+ +-------------+ | | | | | | | Shell | +-------------+ | | | | | | | | | current_screen --------->| Screen2 |------->| Game | | | | | | | +------------------+ +-------------+ | | | | +-------------+ | | | | | | | Screen3 |------->| | | | | | +-------------+ +----------+ (I'm going to have to write a wysiwig ascii-art drawing editor one day...) -- Greg