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?


1 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.

  • \$\begingroup\$ Thanks, I'll try experimenting around with your philosophy, first. I am still inexperience when it comes to designing architecture. This is not because I don't know how to design, but I can't decide on the best approach to solve the problem. It is rather a lot easier to accurately know my next objective and search for solution than to be uncertain of what my next objective is. \$\endgroup\$
    – user1542
    May 21, 2012 at 6:43
  • \$\begingroup\$ If in doubt just toss a coin and go for it, because that's the way you'll learn and in the end the game is the playing experience, not the technology behind it. Your players won't know or care if you applied design patterns or DRY. :-) \$\endgroup\$
    – Eric
    May 21, 2012 at 8:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .