Conceptually, they are different states. One is traveling, and one is battling. You do not, in this case, define the difference of states by the information they do not share - you define it by the different in the interaction they engage in with the user. In Final Fantasy VI (Canadian 3), there were three states, not including menus: Traveling around location, traveling around the world, and battling. Traveling around locations and around the world both require similar amounts of information, but the interactions of each state were different. You could talk to people, hit switches, etc, whilst walking around the location- you couldn't walking around the world. Traveling around the world let you enter location - something you couldn't do from a location. Even though they were both "traveling" states, and required (and displayed!) similar amounts of information, they were fundamentally different. Battling was obviously different again.

Many people (programmers, mostly) make the mistake of defining the difference of states as the dissimilarity of the information they deal with - a leftover perhaps of a very inheritance-driven mentality. This is wrong - although it should be mentioned that the implementation of the states can include inheritance (and probably should).

[Edited by - _goat on May 10, 2007 3:43:22 AM]

@_Goat: I'm going to disagree that travelling around town and traveling around the world map are different states. Continuing with your example of FF3(US/CDN) I seem to recall the ghost town having both the typical town interactions as well as random battles. The same goes for the dungeons. Another point of contention I have is that, when travelling in a town, entering a building is fundamentally the same opperation as entering a town when traveling the world map. FF3(US/CDN) as well as FF5(JPN) are somewhat special cases, as they use mode-7 graphics mode while traveling the world; however I don't feel that that enough difference to call it a different mode -- especially when mode-7 basically ammounts to a neat trick done with a standard tiled mode; if there's any difference at all, its relegated to the rendering code only.

Having written a couple RPG engines myself, I'd assert that having a unified "traveling" state is far more flexible and elegant than separating the world map from dungeons/towns/houses/etc.

The rest of your points are well made.


@GroZZleR: Personally I take the stance that travel and battle are two distinct states, both in concept and in my implimentation. Whether this is implimented through transfering control to a BattleMain() function or by transitioning to a CBattleState class depends on your implimentation. I find the state-class approach to be most flexible and I use it for many things -- The Splash-screen is a state, the title screen and main menu are another state, traveling is a state, battle, shopping, menus... all states.

For RPGs I find that, IMHO, stack-based state machines lend themselves best as you'll want to return to the previous state(s) 99% of the time.

Crap - I changed all the "town"s to "location"s except the most important one (the first one). If you read it as "location" instead of "town" then your first point is invalid, since towns are merely locations without enemies. Your comparison between entering towns and entering buildings has validity though. However, the ability to spawn a battle is something traveling around the world lacks, so I would still categorise them, conceptually as different. You've fallen into the trap a little bit already - just because you can model entering a location from the world map, and entering a building from a location in the same manner, you can't consider them the same concept. But as I tried to point out, implementation is a separate issue from conceptualizing. Using a unified "traveling" state in your code may be worth it - as long as you maintain the segmentation of concept and code states.

And I changed all those towns into locations.

I guess we'll have to agree to disagree. It may simply be a matter of semantics when we really mean to say the same thing though.

To me, the world, towns, dungeons, etc all fall under the definition of "locations" as you put it. The world is just a location with no npcs/scenery to interact with -- only "doorways" into the various towns. Towns are locations with NPCs and Scenery to interact with as well as doorways to other locations and dungeons are (usually) just towns with enemies.

As I think hard about it, the only difference I can recall as far as what you're able to do on the worldmap vs. elsewhere is to use transport (i.e. the airship) -- you can even use the cabin/tent items in certain locations, if an area to do so is given.


The disconnect between us is probably due to different definitions of "state" -- which, for me, means "a self-contained unit of localized functionality mostly independant of other units". Your definition seems to be more along the lines of "States are comprised of common collections of possible interactions".

I always have the battle and world as different game states. Battles in traditional RPG's are basically mini-games.