Best practice game design

Question

Having decided to use java to develop what will be for the most part a 2D (overhead) tile-based RPG game I'm wondering what the best practice is for designing a game like this.
At the minute I'm intending on using a 'state' system, varying game states (main game, shop, battle, world map etc., state transitions and single use states to create further immersion in the game) implement a State interface that defines how the main game engine interacts with the state (mainly a tick method called on each game loop). When the program wants to switch the game state it makes a call to the main engine, something like setState(State).
Has anyone written an RPG along these lines? What kind of memory usage did you have, and did you encounter any problems along the way with this design?

Answer 1

So far, I've identified two perspectives.
The first is to consider yourself as a sort of "overmind" that tracks each object within the game as a seperate entity. The primary advantage seems to be that it is trivial to add objects as you go along. The primary disadvantage is dealing with all the message passing.
For example, say you are fighting a horde of goblins when a dragon flies overhead and breathes fire on the battlefield. You would have to call each goblin instance, and have that particular goblin check to see if it dies, and if so, call its death routine. You would have to call your own player object, and have it check to see if you are carrying potions. Each potion then would have to check to see if it boils and explodes in reaction to the dragon breath. And so on. But it would be trivial to add an orc to the battle, or change the dragon into an evil wizard.
This consumes quite a bit of memory (for all the objects and references), and it can be a little tricky incorporating it into the game loop.
The other aspect is to code the player as the "center of the universe" and everything happens with respect to that player. It becomes easier find relevant objects and interact with them, but it becomes much harder to just drop an object in place.
Using the prior example, the dragon becomes your combatant. Damage is done to a goblin in the array and it dies. The next enemy in your array dies. Do so much damage to your inventory and remove them as appropriate. Keeping track of what's going on appears to be much more straightforward, but it would be harder to add the evil wizard to the mix.
This consumes less memory - the game is only worried about things that happen around you as opposed to well... a whole bunch of "entities" at the same time, and is significantly faster and easier to add to the game loop.
State machines tend to follow this approach, event driven games tend to follow the prior approach.
Obviously, I don't code games for a living. I would think that most games these days are somewhat of a mish-mash. Use a basic state machine as in the FF7 example to keep track of broad activities, and within each activity, let the objects manage themselves in response to events.
For example, each game tick could switch among movement activities, "peaceful magic" activities, battle activities, clean up activities (such as death and xp rewards), and finally general inventory and shop activities, skipping steps as appropriate.
And say within the movement event, you could have an monster object scream and add itself to the battle mode queue if it detects your player object within such and such a distance.
Anyway, I've been toying with the idea of coding or volunteernig to work on an RPG as well, so I'd be interested in hearing from you guys on how to organize things too.