A conceptual question

OK, your half way there anyway, instead of your game loop consisting of a set Render() and Update() though how about allowing it to use one of the followiung structures:

If we have your generic game loop, with blank updates in:

class CGame
{
     virtual void Update();
     virtual void Render();
}

From this we can derive the kind of state you were using:

class CMainGame
{
     virtual void Update();
     virtual void Render();

     // whatever else you were using
}

In the main loop this would just appear as:

CGame *m_currentState;

WinMain()
{
    m_currentState = new CMainGame;

    for(;;)
   {
         m_currentState->Update();
         m_currentState->Render();
   }
}

This should just be similar to what your doing right now, the beauty of this system is you can create your own CGame states now and stick em on m_currentState, be they an intro, a menu, a pause screen, a bonus stage etc, you can lay them out in a stack, just have 1 at a time, however you want really.  An intro will work exactly the same, its update will be small and might just check for a keypress, once its found one or ended it'll close its self and move on to the next state, which will have its own update and render functions. All the while the main game loop remains small, tidy, easy to add to, heavily object oriented and can mainly be kept and improved from game to game.  The menus you mention could be part of the base state (CGame), if the main update spots a certain key is pressed it'll Render() a menu at the top, this would allow the menus to work in ANY state, frontend, main game etc.

If this doesn't make any sense in any way just ask or if your not bothered about OO coding (or using c++ or similar) go for the method above.

that was meant to be:

class CMainGame : public CGame
{
    virtual void Update();
    virtual void Render();

    // whatever else you were using
}

hence all the inheritence jargon, sorry :)

Thanks for your comments Moonover and Peonic.

Penoic your suggestion does seem impressive. I am myself a big fan of OOism and would like to better understand what you are suggesting. So far from what I gather, you are suggesting that I should create subclasses for all the different states that my game can be in. Okay, I create these subclasses for the main game, the intro, the pause screen etc. As my game starts, I initialize the m_currentState var to a CGameIntro object. Now the user presses a key and the update() function of CGameIntro understands that the intro must end now and therefore cleans up. However what do I do next? (My aim was to display a menu at  this point). Also, I do not understand the stuff about menus you put towards the end of your comment. Kindly spell that out in a bit more detail.

Thanks!

Oh and another thing, my basic Gamestate looks like this, all you'd need to add for the stack thing to work is a pointer to a previous state:

class PLN_GameState
{
public:

      PLN_ResourceHandler      *m_resourceList;      //list of sounds/textures/models/scripts and any other resources
      PLN_GameState            *m_prevState;
      char                    m_stateName[32];

      PLN_GameState(char *name);
      ~PLN_GameState();

      virtual int Update();
      
      virtual int PreDraw();
      virtual int Draw();
      virtual int PostDraw();

      virtual int Activate();
};

m_prevState is set up when the stack is sorted out.  As I mentioned before I use resources in a list, thats the handler which EVERY state will be created with, EVERYTHING i use is a resource it keeps the code nice and tidy.  The resources are the same in that they have an update and draw which is handled by the ResourceList from CGameStates update and draw.  This allows the actual states to stay VERY small and readable but keeps the complex code together..

PLN_ActionState::PLN_ActionState() : PLN_GameState("Action State")
{
   m_resourceList->AddResource(m_player = new PLN_ResourcePlayer("models\\players\\sonic", "sonic", "railgun",MD3_MODELCOLOUR_BLUE));
   m_resourceList->AddResource(m_camera = new PLN_ResourceTrackCamera(&m_player->m_worldInfo));
}

The player resource is derived from model resource, which is once again derived from the base resource, its only difference is it checks input and moves the player accordingly playing the correct animation, that's a quake 3 model it loads, it also contains collision checks.  A camera is then set up which tracks the player, to do things like set his position all I'd need to do is set m_player->m_worldInfo.m_position[X] - [Y] or [Z], basically the more stuff you can keep out of your game loop the better, if its tangled up you wont be able to reuse it, as its set out I could add 10 players to a map and allow 9 of them to be controlled over the network or something, once this player class is sorted I can throw it in as many projects as I want.

My Actionstate update:

int PLN_ActionState::Update()
{
     PLN_GameState::Update();

     // tumble weed and church bells

     return TRUE;
}

;) obviously this will have stuff in later, at the mo its just a character running around a map though, nothing specific to this state.

Hi Peonic!

Thanks for your wonderfully detailed answers. I guess now I have a general direction to proceed along. Since you gave such a good detailed answer, I feel compelled to increase the points for this question and award them to you!!

I will keep that thread in my favorites .... that was a good one Peonic!