[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] State Machine Organization



"Simon Oberhammer" <simon.oberhammer@xxxxxxxxx> wrote:

> But why are you referring to those screen instances as "states"? Or is
> this just to keep in tone with the thread?

The overlapping screens are a nice side-effect of the system, the primary
purpose of the system is to manage different states or modes that the game
can be in.

I start off with the intro screens, each of which is a state, go to the
main menu, and from there, presumably the player launches either the
tutorial or the main game. Within the main game, the gameplay cycles from
plannning to execution phases, probably ending up at an end-of-level
display, or perhaps quitting out of the level and going back to the main
menu.

Each of these were implemented as discrete states (and probably a bunch
more besides) - they're not really "screen instances" except in that each
of them draws itself in a different way (like I said, each state object
has its own tiny MVC breakdown within its own implementation.

Although the system could handle arbitrarily deep (well, limited by
memory) stacks of states, I think I ranged from one to three states deep
in my stack, ever - most of the time, I'd transition from state to state
by popping the current state off the stack and pushing the new state on.

The earlier discussion of how to manage a Finite State Machine for a RPG,
with my system, I might have one state for walking around town, and
another state for being inside a shop. Depending on the nature of the
game, that shop state might be pushed on top of the town state, so that
when you leave the shop, you're back in town without having to recreate
the town state. Or, if the shop can actually be a portal to another place
(in Bard's Tale, some shops could be portals to dungeons), it might make
sense to replace the town state with the shop state.

However, if you were to stop an NPC in the street and talk to them, I'd
probably implement the dialog with them as a child state - especially if I
wanted the street scene to be drawn underneath (calling through to the
parent's OnDraw function in something a little like inheritance), but I'd
probably want to remove all the logic of the street scene - the NPCs in
the street moving about, mousetext if I hover over street signs, moving
the PC around the scene - all of that would be disabled because the NPC
dialog state would be getting the OnUpdate and OnMouseDown calls, and
handling them itself.


Does that speak to your question? I'm not sure if I understood it.

-Dave LeCompte