"Simon Oberhammer" <[EMAIL PROTECTED]> 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
