• entries
    15
  • comments
    12
  • views
    28350

More Engine Think...ing.

Sign in to follow this  
Gregory Cheyney

1131 views

For anyone who has considered or is working on RPG engines, at some point we come across the source image that I found in a tutsplus.com article, that refers to a generalized "architecture" for the modules of an rpg engine. This is a good starting point when developing a state-based system, where each state represents a current activity that does not run in parallel to another state. For example, each of the game menus could be states, the game maps could be controlled by one map-controller state, and the beginning and ending(s) could be more states. I've taken this approach before having seen this graphic, but oh boy am I glad I'm on the right track...

The article where I found this image also has other good aspects for a beginner, and perhaps even someone with fair knowledge, to peruse; if you haven't seen it yet, please take a few minutes to look at it here. (In fact, the whole gamedevelopment.tutsplus.com site is replete with a few interesting tutorials and thought-provoking articles; it may be good to follow the site in general.

The Point?


In my case I had originally put all the states as equal sibling Java classes, all descended from the same abstract class; but in reorganizing my work, I found a few interesting facts about the use of states in general, and things in specific I should have realized about classic rpgs when playing them, had I been more analytical. It's these few new facts that will be the basis of additional refactorings of the source code.

  • First, a few states are specifically for application-level notifications and meta-game states: an "engine beginning/initialization" state for when things start up; an "exception-handling" state for capturing and displaying crash states, if possible; and even the "title screen" that shows when the player can select whether to load a game, start a new game, or just exit altogether.
  • Second, a few more states for game specials, such as cut-scenes and interstitial scenes. A cutscene state could be either a playing animation, a "text-roll" or info-dump at the beginning of a game, or a video that gets played. The interstitial scenes, I'm sure you have seen them, are the transitions between "stages" or "chapters" of a game (at least, how I imagine them to be). Another few game special states might be for handling of "game over" events - essentially displaying a background graphic and some ending text, and optionally for asking whether the player would like to continue, resume, or quit.
  • Third, the primary "in-game" states such as map handlers, battle handlers, and such, anything not a menu or system.
  • Fourth, the menus and systems that the game engine will handle, as a part of a supplemental expansion of the "core" play of a game. I say it like this because, it's entirely possible a game could be made for only map-based movement, with no menus, no controllable "systems" such as crafting or item management; yet the game is supplemented with the proper use of such.
  • Fifth, some additional states that may be used while a game is in development, not of use to the intended player. The use of "developer-only" game states may provide some inherent debugging functionality from within the game itself, via displaying the values of some variables, and possibly, through a menu-based selection screen, being able to test-play battle of selected party members versus opponents.

    And perhaps more ways to break it down than that. With obvious compartmentalization like this, menus and systems are only relevant to an in-game playthrough, so they would only be accessible from within an active game. Also, the primary in-game states are only relevant to an active game as well, so they won't be accessible until a game is either loaded or started anew. With a little more introspection, game states can be tweaked somewhat by common functionality and application...
Sign in to follow this  


2 Comments


Recommended Comments

Hi,

Just a simple suggestion, since "been there done that", regarding state and menu handling, and many of the problems / use-cases you mentioned can be solved by a bit more complex state handling constructions!

Check out:
Concurrent State Machines
Hierarchical State Machines


And most importantly, which I believe to be the most useful and flexible for game state management is:
Pushdown Automata

I use the last construct for state handling. Short version:
You have a stack of states, so multiple states concurrently, you usually implement and use the simple case, where the top-most state in the stack is the "Current" or "Active" state. You simply push and pop states, and to simulate the simple state-machine behavior you can add a changeTop function too...
The nice part, that comes with this is that you can preserve the last state(s), so you can easily implement jumping back to previous states (like sub-menus within menus or a cut-scene at some point in the "game-play" state). Also you can specialize the automata for game-state management with some nice tricks, like adding the possibility of update-ing/draw-ing multiple states in the stack by going downwards from the top of the state-stack, and "asking" the states themselves whether to update and/or draw underlying states.
This way it is a simple job to add a "popup" like state for pausing the game-state but still drawing it, like in case of dialog message-boxes or pause and inventory menus which do not cover the full screen.

For more details check this:
http://gameprogrammingpatterns.com/state.html
It is a well put together source for other patterns too, useful for game-dev.

Br.


P.S:
Haven't read through every point of the article until now.
Sry for the long comment, essentially it suggested something really similar I did.

Share this comment


Link to comment

Yes, I do something like a Stack; and I'm quite fine with long posts -- if you haven't noticed, I often tend to do them, myself.

 

I find it odd to see code examples that are essentially a one-dimensional "array" of states, which means all states are always instantiated and taking up memory throughout the game; it seems it would be far more operationally smooth to instantiate states only when necessary.

 

In my case, since it's an "rpg maker" engine I'm talking about, I do something special: the primary StateManager class has a field for the current state, a field for the "next" state (for transitions to a new state), and the stack of previous states to pop back to. This way, I allow a current state to set the next state, where in the following tick, the current state may be pushed into the stack and the next state becomes the current one, for proper transition and so I don't have to worry about overwriting the current state at any time. -- This "previous state stack", I hope, is a good idea for keeping a succession of states that popped back to; it's like having a map instance for the overworld, pop that back and place a town map, pop that back and place a building-interior map, and so on, to which we could pull out the "parent" map state, until arriving at the overworld again.

 

Anyway, what I was inferring with the five bullet-points, was that each of those bullet points is controlled by its own specialized "State Manager" class, so things are tightly compartmentalized. Well, there's a bit more to it, but ... it's a work in progress....

 

Edit:

Upon reading that link you gave, I see what I'm going for is very much already a combination of hierarchical state-based system and a pushdown automata, like you mentioned. I sort of came up with the idea a while ago, but thanks for the link, so that I could read up a bit more about all of that.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now