Организация внутриигровых меню

Всем доброго времени суток. Недавно я начал делать свой рогалик на SDL и у меня возникли проблемы с организацией менюшек. В прошлой игре (тетрис) я управлял состояниями меню и игры через switch-case а потом кое-как в состоянии меню рисовал разные виды менюшек (главное меню, меню паузы и т.д.), вообщем получилось не очень. В новой игре я решил это все получше организовать, почитал про менеджеры состояний и пока сделал как-то так:

//менеджер состояний
class StateMgr
{
  State* States[2];
  State* CurrentState;

public:
  StateMgr();
  ~StateMgr();

  void AddState(State* state, int nstate);
  void ChangeState(int nstate);

  void OnEvent(SDL_Event* Event);
  void Update();
  void Render();

  void Cleanup();
};

//класс-родитель для состояний
class State
{
public:
  State();
  ~State();

  virtual bool Init();

  virtual void OnEvent(SDL_Event* Event);
  virtual void Update();
  virtual void Render();

  virtual void Cleanup();
};

//Игровой цикл 
    enum
    {
        GAME_STATE,
        MENU_STATE
    };

  SDL_Event Event;

  GameState* gState = new GameState;
  MenuState* mState = new MenuState;

  SMgr.AddState(gState, GAME_STATE);
  SMgr.AddState(mState, MENU_STATE);

  SMgr.ChangeState(GAME_STATE);

  //--------------------------

  while(Running)
  {
    //обработка событий
    while(SDL_PollEvent(&Event))
    {
                    SMgr.OnEvent(&Event);
                }
    //выполнение шага и отрисовка
    SMgr.Update();
    SMgr.Render();  
  }

Вопрос в том, как лучше быть с внутриигровыми меню (инвентарь, информация о персонаже)? Делать их такими же состояниями как и главное меню? (но тогда будут проблемы с доступом к информации из состояния игры) Или в состояние игры добавить еще один менеджер состояний? (имхо, слишком запутано и расточительно будет) Или лучше сделать как-то совсем по другому?

Блин народ... ну вы хоть книги иногда читайте... На эти вопросы полно ответов. http://www.sugardas.lt/~p2d/books/Priemioop.pdf

Стас
И какой же паттерн ты рекомендовал бы употребить в этом случае?

Стас, http://cnb.uran.ru/userfiles/213530.pdf - уже давно вышло второе издание книги про паттерны.
В моей игрушке за всеми состояниями следит один класс, и проблем с доступом нету. Тут уж смотря как продумать хранение и доступ к этой информации.

За книгу спасибо, почитаю. Но все таки ответа на свой вопрос я там не нашел. Из подходящего к моему случаю увидел только паттерн State, но что-то подобное у меня уже есть.
NetFox
> В моей игрушке за всеми состояниями следит один класс, и проблем с доступом
> нету. Тут уж смотря как продумать хранение и доступ к этой информации.
Допустим, я храню информацию так, что ее видят все состояния (что уже, по моему, не очень хорошо). Что делать, если я захочу сделать фон вокруг меню прозрачным? Копировать код рендера из класса состояния игры в класс рендера каждого меню?

Olaf85
> И какой же паттерн ты рекомендовал бы употребить в этом случае?
Один? Я бы рекомендовал почитать книгу, ту что я указал, или любую другую по ООП и ООД. Один паттерн погоды не делает.
Они всегда используются пачками. Для решения конкретно этой задачи, можно задействовать много паттернов. Фабрику, Синглтон, Состояние. В случае необходимости можно подключить и другие.
Можно задействовать объектный пул. А можно не использовать ни чего из выше перечисленного и просто сделать:

TiBx
> В прошлой игре (тетрис) я управлял состояниями меню и игры через switch-case а
> потом кое-как в состоянии меню рисовал разные виды менюшек (главное меню, меню
> паузы и т.д.),

А то что:
TiBx
> вообщем получилось не очень.
Так для этого и пишутся любительские проекты, чтобы понять что получилось не очень, и как сделать по другому.

TiBx
> Допустим, я храню информацию так, что ее видят все состояния (что уже, по
> моему, не очень хорошо). Что делать, если я захочу сделать фон вокруг меню
> прозрачным? Копировать код рендера из класса состояния игры в класс рендера
> каждого меню?

У меня была с кнопками похожая проблема. Рисовались в каждом состоянии свои кнопки. Но потом при смене их - приходилось менять по всем состояниям.  Проблема решилась переносом кнопок в отдельный класс, который и следил за их отрисовкой. Инкапсулируй, то что будет меняться независимо от состояния тогда.