Game states and view relationship

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Game states and view relationship

      Let's say our game has three main states
      -Intro
      -Main menu
      -Game

      Since the BaseGame class holds the states, that seems to fit in fine. However, since each of these states are so different, would it call for three different views? Or would it be recommend that there is only one view, but it also has three states?

      I would think three different views since each view contains the elements it presents. This would still seem to work fine for network games since only the main Game state has actual network relationship.
      -----------------------------------
      Phillip McCartney
      www.IWantToMakeIt.com

    • RE: Game states and view relationship

      Hmmm, if it were me, I'd have three different views. And pie. Gotta have pie.... (or PI?)

      -Rez

    • States

      The BaseGame and its derived objects will still become too crowded handling all the states and substates (like fade-in, loading, etc). I am playing around with a State object the BaseGame creates who takes care of everything. The base game knows its state machine, and creates the appropriate State object who does everything related to the state it might be in.

      No pie needed.
      -----------------------------------
      Phillip McCartney
      www.IWantToMakeIt.com

    • RE: Game states and view relationship

      I think everyone is when they first hear about the model-view-controller pattern, which this design is somewhat based off of. I remember when I first learned about model-view-controller, I thought "Why would anyone want to do that?!?!" I think you have to make mistakes a few times before you realize the true power of it.

      For me, pointers were the same way. When I was a fledgling week-old programmer first learning about pointers, I thought it was the most ridiculous thing ever. Why would anyone want to go through the extra step of dereferencing? It's all a learning process. :)

      Barbie & Ratrace do a really a good job of hiding some hardware and OS specific code, but exposes a lot of other stuff. I wrote a Direct3D-specific function in one of our Actions (analogous to Processes in GCC). I still feel dirty.... There are tons of places where we make Win32 calls or D3D calls where we shouldn't. We have a whole Graphics Skin project that does nothing but acts as a layer of abstraction between rendering specific calls and the engine itself. For example, we have a SegTexture class with functions that call the Renderware-specific functions needed to do something interesting with the texture. In our Ogre build, those same functions call the ogre equivilants. In retrospect, I probably should have built up a SegTexture when switching the locker texture in Barbie, but there was no easy way to do this so I just used D3D. In crunch time, all bets are off.

      Thus ends my ramble for the day. Also, six days until GM! And I have Barbie songs stuck in my head! Time to rip them out with good ol' NIN.

      -Rez