I'm at the beginning of my first game in C++ (but not my first game overall) and I find myself trying to find a suitable solution to managing game state. First of all let me just give you a short run down on the three code files I currently have:

main.cpp
----------------------------------
Contains 3 methods:

- WinMain: Handles the creation of the windows class, registers it and creates the window, shows it and updates it. It then returns Run()

- WinProc: The usual switch(message) handler and returns DefWindowProc()

- Run: Contains the MSG and the main game loop


game.h/game.cpp
----------------------------------
private: int screenWidth, int screenHeight, LPDIRECT3D9 d3d, LPDIRECT3DDEVICE9 d3ddev.

methods:

- Constructors: Sets the width and height
- InitD3D: Creates direct3d interface and declares settings (such as not windowed and back buffer settings). Also creates device on d3d.
- RenderFrame: Clears the window to black with no cursor and starts and ends a 3D scene and creates a frame
- CleanD3D: releases both Direct3D variables.

Game is declared as a Pointer in main.cpp. RenderFrame is executed in the main game loop and is initialised in WinMain.


Onto my main post I thought it'd be best to explain how my program is working. My idea for state management is to have a new class called GameState with a few methods:

Constructor: For initialising
Update: For updating the game logic
Draw: For drawing the frame to the screen

So when I create a screen such as menu screen for example (which I will have) I can inherit from the GameState class. All I would then need to do is have an object of GameState in main.cpp, assign it to the menu screen object and call currentScreen.Update() and currentScreen.Draw() in the main game loop to run that game state.

I haven't yet figured out a way of menu screen telling game state to change to the next screen (ie the game screen). Is this a good idea or am I going the wrong way about this?

It sounds like you are going for a game state manager similar to the one described here
I have been using this technique with great success myself, but I know some would argue that it is overcomplicating things and that a simple enum would do just fine (I didn't mention Sneftel did I?)

Ah yes that does look quite similar to what I want to do except that I think mine is much simpler. That's using at least two classes to handle state whereas I'm using only one and it has a lot more methods as well.

Although I will take an idea from that example in the way that they handle state changes, I can't see any other way of doing it.