Переключение между различными экранами одного и того же типа состояния?

Кажется, вы разрываетесь между объектно-ориентированной и процедурной парадигмой обработки переходов между состояниями. Другой ответ, предлагающий оператор switch для обработки перечисленных изменений состояния, является хорошим процедурным способом сделать это. Недостатком этого является то, что вы можете получить монолитный игровой класс, содержащий весь код и все лишние данные, относящиеся к состоянию, для обработки вашего события/логики/рендеринга для всех возможных состояний. Объектно-ориентированный способ справиться с этим намного чище и инкапсулирует их в свои собственные отдельные объекты состояния, где их можно использовать полиморфно через общий интерфейс. Затем, вместо того, чтобы хранить все детали для обработки всех состояний в вашем игровом классе, вашему игровому классу нужно только хранить указатель состояния и не беспокоиться о деталях реализации конкретного объекта состояния. Это переносит ответственность за обработку переходов состояний из игрового класса в класс состояний, которому он принадлежит. Вы должны прочитать о шаблоне состояния/стратегии из книги шаблонов проектирования. Обработка изменения состояния должна быть обязанностью самого объекта состояния. Вот немного чтения:

http://www.codeproject.com/Articles/14325/Understanding-State-Pattern-in-C

http://sourcemaking.com/design_patterns/state

http://sourcemaking.com/design_patterns/state/cpp/1

http://codewrangler.home.comcast.net/~codewrangler/tech_info/patterns_code.html#State

http://en.wikipedia.org/wiki/State_pattern

http://www.codeproject.com/Articles/38962/State-Design-Pattern

Цитата из книг «Шаблоны проектирования» и «Архитектура программного обеспечения, ориентированная на шаблоны»: Подход, основанный на шаблонах, использует код вместо структур данных для определения переходов состояний, но хорошо справляется с действиями переходов состояний. Шаблон состояния не указывает, где должны быть определены переходы между состояниями. Это можно сделать в объекте контекста или в каждом отдельном производном классе состояния. Как правило, более гибко и уместно позволить подклассам состояния указывать свое последующее состояние и время выполнения перехода.

У вас есть возможность создавать объекты состояния заранее и никогда не уничтожать их, что может быть полезно, когда изменения состояния происходят быстро, и вы хотите избежать уничтожения состояний, которые могут вскоре снова понадобиться. С другой стороны, это может быть неудобно, поскольку контекст должен содержать ссылки на все состояния, в которые можно войти.

Когда состояния, которые будут введены, неизвестны во время выполнения, а контексты изменяют состояние нечасто, предпочтительно создавать объекты состояния по мере необходимости и затем уничтожать их. При определении того, что использовать, вам необходимо учитывать стоимость, а также частоту перехода.

Отличное объяснение вашей проблемы, прежде всего.

Часть вашей игры, управляющая заставкой, может работать двумя способами. Вы изучили проблему, и она действительно так проста:

Получить ввод; установить следующее состояние.

Итак, примеры:

 STATE_SPLASH1
 STATE_SPLASH2
 STATE_SPLASH3
 STATE_TITLE
 STATE_GAME_INIT
 STATE_GAME
 STATE_EXIT

псевдокод:

state = STATE_SPLASH1

while (state != STATE_EXIT) 
  ... receive input ...
  ... process events to responders ...
  ... update ...
  ... yadda yadda ...
  switch (state) {
    case STATE_SPLASH1:
      show_splash1()
    case STATE_SPLASH2:
      show_splash2()
    case ..:

    case STATE_TITLE:
      show_title()
    case STATE_GAME_INIT:
      show_loading()
      setup_level()
      setup_characters()
    case STATE_GAME:
      game_update()
    case STATE_EXIT:
      cleanup_and_quit()

Другой способ — управлять заставкой «состоянием игры», а затем состоянием заставки как внутренним состоянием. и когда у заставки больше нет логики для запуска, установите состояние игры на следующее. Когда я учился, я обнаружил, что источник DOOM является ценным ресурсом и человеком, это не что иное, как сотни конечных автоматов. :)