Sign in to follow this  
GroZZleR

The World and the Game State - Separate Things?

Recommended Posts

Hey all, Imagine a 2D RPG where the battles don't take place directly on the world map (eg: FF3 not Oblivion). You have two states: travelling or battling. Are these two separate states (TravelGameState, BattleGameState), are they one game state (PlayGameState) or are they something else? World & Battle both need: - Detailed party information - State of the world (quest progress, city status, etc.) But there's a lot of information that each GameState doesn't need to know about the other. Battle probably doesn't care what cities are on the map, or if 13, 7 is an ocean tile, for example. So what do you do? Do you separate the world from the GameStates in some sort of "world database" that any GameState can query? Are they the same GameState (PlayGameState) but running different logic? Ideas?

Share this post


Link to post
Share on other sites
I don't know how it was done on the consoles, but on the PC I would make the battle state contained within the world state . I conceptualise battles as springing forth from the travelling portion of the world, so the world would call a routine that creates a battle instance with whatever parameters are appropriate for that time (random monsters, whatever monster you just bumped into, boss fight etc.). The usual travelling portion of the world would be put on pause until the battle was complete.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
@_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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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".

Share this post


Link to post
Share on other sites
I'd say to keep the common information in a separate system than the current game state. The game state should just contain the information needed by the state, while information needed throughout the entire game can be kept elsewhere (your "world database" idea).

I'm guessing that old console RPGs (which were probably written in assembly language) just stored this sort of information at specific addresses, basically using global variables.

Share this post


Link to post
Share on other sites
Thanks everyone. It looks like there's a lot of pros and cons to all approaches, so I'll have to figure out which one suits my personal taste best.

Rate++ all around.

Share this post


Link to post
Share on other sites

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

Sign in to follow this