Re: [pygame] State Machine Organization

[Kris Schnee <kschnee@xxxxxxxxxx>]

Andre LeBlanc wrote:
> I've spent the past 24 hours or so looking through the source for the 
> PGU Engine and Phil's Pyweek3 example code, and its convinced me that I 
> need to do alot of re-writing.  I'm trying to figure out how to best 
> organize the various states of my RPG, but I'm a little stuck.  should a 
> state be responsible for all of the rendering at a given time?  for 
> example in the case of a top-down RPG, Walking around town is a state, 
> being in a battle is a state, but what about talking to an npc or a 
> vendor in a town?  This would have to bring up menus for the user to 
> navigate, but the scenery in the town should still be painting. NPCs can 
> walk around while you are talking to a shop owner, so should that be a 
> separate state?  I like the way the 'rooms' were subclassed and imported 
> for the pyweek3 game and that's what I'm going for, but how would you 
> transition between these 2 states, if indeed they should be separate.

The way I'm organizing the different states of my game is something like 
this. I've got a main Game class with a function called Notify, that 
takes messages from the interface or elsewhere. Then there are functions 
like WanderingScreen that set some overridden version of Notify and 
create one of several interface objects. Then there's a main loop that 
switches between the various "Screen" functions until one of them 
changes the Game object's state to "quit." Paraphrased code:

<code>
def WanderingScreen(self):
    self.interface = 
WanderingScreen(screen=self.screen,pen=self.pen,input_pen=self.smallpen,parent=self)
    self.Notify = self.NotifyOnWanderingScreen
    done = False
    while not done:
        pass ## Do stuff

def Go(self):
    """This is the main loop of the game.

    Go between various screens until the game is over."""
    game_over = False
    while not game_over:
        ##print "Returned to main loop. Now switching to: 
"+str(self.game_state)
        function_to_call = 
self.functions_for_each_game_state.get(self.game_state)
        if function_to_call:
            function_to_call()
        else:
            game_over = True
    print "Game over. Thanks for playing!"

</code>

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."

So, adding a new screen to my game involves creating a new class of 
interface, adding a new version of the Notify function, and adding a 
Screen function to switch to. I was thinking lately that a simpler way 
to do this system would be to eliminate the different "Notify" functions 
and just do something like:

def Notify(self,message):
	self.messages.append(message)

And then the Screen functions could just read through their messages and 
process or ignore them however is appropriate.