I have been working quite regularly lately on the states, and what is resulting from this effort is quite a few game states, just waiting to be implemented.
- A few of them are for application-level activity (game loading/initialization, error state, application closing).
- A few are for the more-than-one game endings possible (lose, win normally, and win "secret" or "extra-special" ending); many players might actually like to get that special ending. While we generally only need one "fail" state, we could potentially have multiple "winning" states. I happen to refer to console games like Suikoden II, et cetera, which might show something slightly different, based on how the game ended (such as who saved/not killed/et cetera).
- A few are specific to "cutscene" handling (one for animated, one for "chapter" interludes, one for text-roll (scrolling text), one for playing a pre-recorded video scene, et cetera). The animated cutscene I refer to is from games like "Tactics Ogre: Knight of Lodis" and "Final Fantasy Tactics", where between battles, we may see an interlude with a static background, and the character sprites, and some often-tense moments of dialog. For such an animated cutscene, these elements are typically scripted or evented in a static fashion, but could reflect earlier player choices quite well. Character sprites can change their facing, and characters themselves could move within the limits of the screen.
- And the rest of the states for active game-play and menuing states. More on the active map state later; but the in-game menu screen is initialized and controlled from the game-menu state. The outer main menu allows for opening sub-menus, to check the condition of characters, inventory, et cetera, or to perform some general task.
Why so many states, might you ask? One primary reason is ease the transitions between one part of a game to another part, such as from playing on a game map, and then opening the in-game menu; we want to keep the in-map state, merely 'pushing' it aside, then opening a menu state to take its place; afterward, we merely close the menu state and 'pull' the game state back into view.... Also, these states link back to the game objects, so we do not lose our state values. Each state that is first pushed aside, keeps in memory its values, so when it is pulled back into view, we should have little to no delay of play, no clunky interaction, just smooth transition and correct values (hopefully).
In developing this editor and engine system, I have found that Java's aging Stack object was used to "push" and "pull" objects into and out of a flexible collection; but since Stack is no longer recommended, I will use the more modern Deque collection interface in a "LIFO" process. Last In, First Out. For our game, an object that is "pushed" into the "head" of this deque will be the first one to be "polled" from the deque.
In my state-manager class, I have a Deque collection for the states that are pushed into it, and a single state class instance for the active state. The parent of every usable state is an 'AState' abstract class, with a constructor which contains a parameter reference back to the 'StateManager' controller class. The states have methods for drawing and updating things in it, as well as to "help" the StateManager with handling when the state itself is pushed or polled.
Some states might naturally be cancelable; for example, we who develop rpgs might be proud of our cutscene; but we also know that some players just want to "skip it" and go straight for the game-play. Myself, I do like actually seeing a good cutscene every now and then; but the cutscene states should be customizable to allow skipping them or not. On the other hand, some states -- like saving an active game -- should NEVER be interrupted in mid-save, unless we are going to perform cleanup on broken game saves after-the-fact.
One state is the map state, which handles all maps and map transitions. In fact, the map state would also have a Deque of its own; it does for maps what StateManager does for states: provides a way to "push" into and "pull" from the deque of maps, so that transitioning from an overworld map, to a town map, to a building interior map, will keep each "parent" map to return to. Exiting a building interior will return us to the town map; exiting the town map will return us to the overworld; all without need to re-load each map from disk -- with the albeit minor proviso that each map in the deque is still somewhere in memory. But I agree that most fairly-modern computers should have enough memory to make this a somewhat moot point. What is it, about two or three Megabytes of memory-space per 500x500 map (in RPG Maker) with events? (I could be off on my estimates; I haven't done any profiling of RM games.)
The "Battle Scene" is for the battle system management; it is meant to launch a combat scene when encountering an actual "monster" in a game. (For some reason, I still don't like the term 'monster' for the encountered events; 'enemy' seems somewhat better but still somewhat generic.) I have been doing further work in generifying the battle system components, so that we can have a basic battle system and multiple specialty battle systems, all in the same game, and used where necessary. Front battle, side battle, tactical battle, each one its own battle system (I think, haha). I am still working on just how or where to initiate the battle event; but that's a problem for a different day. (I'd be the first to admit I wish I knew more about using the battle systems in rpgs; feel free to educate me in what is needed for an rpg battle system.)
Somewhat new to rpg-maker engines, is the fact that I want to provide an extensible Crafting System; like our Battle System above, crafting also inhabits its own state class, instantiating our crafting menu as we launch it. The crafting state is for taking raw materials in a player's inventory and transforming them into more utilizable resources, tools, or consumable items.
And since the "Title Screen" is a state in and of itself, we can extend the static background and menu buttons a bit, perhaps even parallaxing the background somewhat into multiple image layers; in one idea I had, it would be more interesting to designate these as a skybox (background atmosphere), a background terrain/horizon, a near-ground content, and a foreground/focus imagery. We might even have the skybox part moving slowly, to imitate a semi-active scene; and perhaps even weather effects affecting one or more background layers. Buttons might have visual effects such as sliding in from a side, or a textured "glint" or color change. Where such a title-screen system might be useful to a game, would perhaps be in a game with its own unique theme, rather than what ordinary static background imagery can provide.
Finally, I have given some thought to the general order of much of the above; with Enterbrain's products, if we want a "cutscene" to start the game, we could start with a blank map bearing a relevant background, perhaps scrolling text, or some effect; but it's not quite the same as what I originally wish for. In my implementation, I would allow starting with any of the aforementioned states, as the game's starting point -- so the starting game experience could be quite a bit more customizable, to the theme of the game, even a "character customization scene" if so required.
Granted, all of the above thoughts may not be "perfect", but I would like to assure my readers that I have, indeed, put a lot of thought into how we put a game together, using what is possible in Java gaming. That I do intend for this to be, and remain, an open-source project is no small feat; the primary reasoning is a hope that it will be a useful alternative to Enterbrain's RPG Maker series of editors/engines. I am, and always shall be, awaiting thoughtful commentary.
