Class design for instantly switching between free-roaming world to/from battle world?

Question

I plan to have an isometric world, which can be freely roam around. However, I desire the system to instantly apply the grid onto isometric world for battling system on any random encounter. Therefore, from what I expect, I should have a class of character that can generally switch between free-roaming and battle system. However, because I am still new to game programming, I do not know how should I approach this. If I make my character class such that I could abruptly derived it into either Free-roaming or Battle system, it may sound convenient, but I will have to implement this feature for all other class too (enemy, object, etc.). If I use Interface, then I won't have flexibility to add extra function to certain special class of object (maybe boss?). Or should I have a set of hierarchy of interface to tackle this problem? If so, it would be too complicated. Therefore, any suggestion?

Answer 1

Two "philosophical" points:

1. Whenever, after making a design decision, you say "I will have to implement this feature for all other class[es] too" it means you aren't modeling the desired behaviour in the most efficient way ("Carve nature at its joints." -- Plato). In general: Don't Repeat Yourself (DRY).
2. Don't confuse classes and objects in your code with classes of concepts and real-world objects. They are ways to organize code - to DRY - nothing more, nothing less. For a concrete example of this, see: How to avoid game objects accidentally deleting themselves in C++ (A game object's death is confused with calling delete on the object that represents it.)

I say "philosophical", because you will need to ignore the above and learn it yourself through experience, so here's my suggestion:

Use a state machine to switch your game object's behaviours

Your game has two states: free-roam and grid-battle. So make those two into sub-states of the "playing the game" state. See http://create.msdn.com/en-US/education/catalog/sample/game_state_management for an XNA-oriented approach. In free-roam you use a camera that's attached to the player character, in grid-battle you render a hex-grid and lock the camera in a fixed position for an overview of the battlefield.

For your game objects, you can reference the State design pattern, which is a more generic variant of the previous link. It enables you to change an object's behaviour depending on its state. Whenever your game's sub-state switches (from free-roam to grid-battle or vice versa), you will need to switch the relevant game objects states as well.

A possible class hierarchy is this:

• GameObject { setGridBattle() setFreeRoam() }

  • class PlayerObject { move() { this.state.move(); } }
  • class BossObject { move() { this.state.move(); } explode() { this.state.explode(); }

• interface GameObjectState

  • interface PlayerObjectState { move(); }
    • class PlayerObjectGridBattle { move() { moveOverGrid(); }
    • class PlayerObjectFreeRoam { move() { moveFreeRoam(); }
  • interface BossObjectState { move(); }
    • class BossObjectGridBattle { move() { moveOverGrid(); } explode() { boom(); } }
    • class BossObjectFreeRoam { move() { moveFreeRoam(); } explode() { /* nothing happens */ } }

Expanding on this could have a MovingObject and a MovingObjectState, from which PlayerObject/EnemyObject and PlayerObjectState/EnemyObjectState inherit, maybe in that case EnemyObject gains a doAI() method, but the move() method from MovingObject (and MovingObjectState) is shared between PlayerObject and EnemyObject.