Организация состояний (меню <=> игра <=>)

Привет!

Вопрос для опытного девелопера является смешнам, но я  восновном работал с готовыми игровыми движками вроде unity, теперь вот возникла необходимость писать всё самому.
В связи с этим прошу подсказать, как наилучшим образом организовать игровые состояния, главное меню, геймлей1, геймплей2.

Допустим есть игра, в которой кроме главного меню, титров есть разные механизмы геймлея - полёт на самолёте, езда на танке, паззл.

switch и case как-то не очень,
Указатели на ф-ию, или указатель на базовый класс, ну вроде:

class Game
{
    Game() {}
    virtual ~Game() {}    

    virtual void Load() = 0;
    virtual void Unload() = 0;

    virtual void Update(float deltaTime) = 0;
    virtual void Render() = 0;
};

class MainMenu : public Game {...};
class AirplaneFly : public Game {...};
class TankDrive : public Game {...};
class PazzleMode : public Game {...};
class Credits : public Game {...};

А в недрах главного цикла есть указатель на Game, который выставляется на нужного наследника, который имеет необходимую реализацию ф-ий.

Это нормальное решение?

Riddik
У нас похоже сделано, все работает.

Помеха
Для мобильных платформ тоже?
Таблица виртуальных ф-ий вроде не медленнее того же  старины switch работает, но мало ли?

Всё норм так работать будет.

Riddik
Хочешь сказать что switch убивает всю производительность в хлам?

Riddik
> Таблица виртуальных ф-ий вроде не медленнее того же  старины switch работает,
> но мало ли?
  Не о том думаете, если выбираете что будет меньше тормозить в меню :)

http://lspiroengine.com/?p=351
http://lspiroengine.com/?p=361

можешь ещё глянуть в исходниках 3-ей небулы.

а вообще,
https://www.google.com/search?&q=managing+game+states

Геймплей одно, UI другое. UI стартует геймплей, например AirplaneFly.Start(). Геймплей вызывает какие-то базовые(публичные) функции UI, например покажи PauseMenu. Они чуть-чуть знают друг о друге, но живут параллельно.

Всем спасибо!

nes
> Хочешь сказать что switch убивает всю производительность в хлам?
Нет. Хочу сказать, что на первый взгляд этот вариант не очень удобен.

Zefick
> Не о том думаете, если выбираете что будет меньше тормозить в меню :)
Только не в меню, а в более тяжелых сценах)

Работа с состояниями организуется через обычную state machine-у (машину состояний).
Это же классический алгоритм.

Хм. Если так делать, как написано в ссылках - то память всё растёт и растёт, ведь очистка памяти идёт только при выходе из программы.
Допустим:
Главное меню, потом запихивается геймплей1, а когда будет геймплей2 в памяти будет хранится и меню и геймплей1.

Lazer
А что мешает добавить выгрузку предыдущего состояния перед загрузкой следующего?

Riddik
> Для мобильных платформ тоже?
да, именно для мобильных платформ.