How should I structure moving from overworld to menu system / combat?

Posted by persepolis on Game Development See other posts from Game Development or by persepolis
Published on 2012-02-22T07:36:51Z Indexed on 2012/03/23 17:41 UTC
Read the original article Hit count: 221

Filed under:
|

I'm making a text-based "Arena" game where the player is the owner of 5 creatures that battle other teams for loot, experience and glory. The game is very simple, using Python and a curses emulator.

I have a static ASCII map of an "overworld" of sorts. My character, represented by a glyph, can move about this static map. There are locations all over the map that the character can visit, that break down into two types:

1) Towns, which are a series of menus that will allow the player to buy equipment for his team, hire new recruits or do other things.

2) Arenas, where the player's team will have a "battle" interface with actions he can perform, messages about the fight, etc. Maybe later, an ASCII representation of the fight but for now, just screens of information with action prompts.

My main problem is what kind of design or structure I should use to implement this?

Right now, the game goes through a master loop which waits for keyboard input and then moves the player about the screen. My current thinking is this:

1) Upon keyboard input, the Player coordinates are checked against a list of Location objects and if the Player coords match the Location coords then...

2) ???

I'm not sure if I should then call a seperate function to initiate a "menu" or "combat" mode. Or should I create some kind of new GameMode object that contains a method itself for drawing the screen, printing the necessary info? How do I pass my player's team data into this object?

My main concern is passing around the program flow into all these objects. Should I be calling straight functions for different parts of my game, and objects to represent "things" within my game?

I was reading about the MVC pattern and how this kind of problem might benefit - decouple the GUI from the game logic and user input but I have no idea how this applies to my game.

© Game Development or respective owner

Related posts about architecture

Related posts about rpg