[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] State Machine Organization
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