I'm working on a 2-d RPG, Final Fantasy style. I'm almost finished my battle component (I've started with windowing and battles, then I'm going to work on inventory, spells, maps, etc.). I'm at a point now where I have to worry about two different states, and I'm not sure what to do. The way I was thinking of handling it, was to embed the code to handle the state whenever that states appears. For example, if you press the up arrow key on a map, then you're in the state of "map", and it will move your character up and scroll the game world down (and other stuff, probably). If you press up while in the menu, it moves the menu item up. Each state will also handle it's own graphic processing. I figure any state can be transferred into, and out of. Each state should have a "start" function that will transfer into that state, and then when the start function is finished executing, you are returned back into the initial state. For example: Main screen --> Load game.start() --> Map.start() --> Battle.start() --> Returns to map --> Inventory.start() --> Returns to map --> (User quits) returns to Load game --> Returns to Main screen --> Exits. Accoring to this book, you should create stacks for each state, and then provide each state with functions like "handleKeyboard()", "preRender", "renderFrame", "postRender", etc, and then push and pop the states onto a stack, and call the appropriate functions on the top element of the stack (the current state) as needed. I feel like that's probably a more elegant approach, but a bit complicated for my first game. Any opinions on this are appreciated :)

Well, just look at what's going on with the data in each method. Doing it your way, you'll lose whatever was going on in the last state and start from a blank slate each time. This is probably fine, if it's a first game.

Doing it the book's way just involves extending the state concept so that it can save detailed information about where it was - and if you have a complex enough engine that can be useful. But it's really more of a thing that you add when you come to a point where it's needed, than a "must-have."

I realize that Jim gives the code, but for some reason it just isn't sinking into me.

I'm not sure how complicated my game engine will end up being. I'm figuring that the Battle Engine (which is consisted of 2 classes) will end up being one of the biggest parts, and so far, it's about 2000 lines. It does use code from my windowing classes and BattleCreature classes, but I consider it separate components, and manageable. If a class stays under 500 lines, I usually have little trouble keeping track of it and making updates.

I should probably focus on getting done as much as I can, since I'm a student and barely find time to work on this, and once I get a job making games worry about doing it well ;)

Thanks! I need to remind myself, again, "Premature optimization is the root of all evil"

Quote:
Main screen --> Load game.start() --> Map.start() --> Battle.start() --> Returns to map --> Inventory.start() --> Returns to map --> (User quits) returns to Load game --> Returns to Main screen --> Exits.

Accoring to this book</a)

I think this link Is more convient
this book

remember to use target="_blank" its really annoying having to open up all the links in the same window!