Game states

<Charybdizs> I've been struggling with a programming design question
<Charybdizs> http://www.gamedev.net/topic/665255-standard-structure-of-a-large-scale-game/
<Charybdizs> I was wondering if you could shed any light on it
<SSNTails> hey, sorry, i left irc on
<Charybdizs> I knew you were afk, no issue
<SSNTails> well, there really isn't a straight answer to your question
<SSNTails> what we do is have a 'core' engine, and then each game project implements certain function hooks that the core expects to be there
<Charybdizs> I'm not looking so much for a straight answer as much as I am for like
<Charybdizs> SOMETHING other than what I have there
<SSNTails> what you have there is certainly very doomy, heh
<Charybdizs> and more than that, how to handle one time events in a continuing loop
<SSNTails> you could have a base GameType class, that Pinball and Adventure classes inherit from
<SSNTails> and they all implement a base set of functions defined in the GameType parent class
<Charybdizs> without making something stupid like a variable "DidILoadThisCrap"
<SSNTails> like our UI system...
<Charybdizs> Hmmm
<SSNTails> everything that's a part of the UI inherits from a parent class called 'Control'
<SSNTails> A button is a control, an image is a control, a textbox is a control... anything you make custom is a control
<SSNTails> when a class is a control, it is required to implement certain functions
<Charybdizs> but different parts of the game have different UI setups
<Charybdizs> what determines which setup it's currently using?
<SSNTails> have you done any WinForms in C#?
<SSNTails> each window is a 'Form' class
<SSNTails> which can contain a bunch of controls
<SSNTails> so, you make a class called ShopMenu, inherits from Form
<SSNTails> in the ShopMenu constructor, you create Buttons, Images, TextBoxes, etc. and add them to the ShopMenu
<SSNTails> in Wizard2, you just do something like:
<SSNTails> ShopMenu *menu = new ShopMenu();
<SSNTails> FormHandler->AddForm(menu);
<SSNTails> and the menu is created, and pushed to the top of the stack of active screens
<Charybdizs> Nah, I haven't actually
<SSNTails> so you could make a ShopMenu, MultiplayerMenu, OptionsMenu, etc.
<Charybdizs> I've usually written my own gui for the learning experience
<Charybdizs> that sounds very understandable though
<Charybdizs> so yeah basically what you're describing is what I said
<Charybdizs> a menustate
<Charybdizs> that changes depending on what the game currently is doing
<Charybdizs> and you'd use something like an if statement or a switch to alternate between them
<SSNTails> hmm? give me an example
<SSNTails> like if you have a MainMenu, then show an OptionsMenu. Main menu is still there, just behind the Options Menu. User clicks 'Back' from the Options menu, and the Options menu kills itself and the old MainMenu now is in front
<Charybdizs> oh
<Charybdizs> okay that makes sense
<Charybdizs> I misunderstood at first
<SSNTails> you typically let each menu mind its own business
<SSNTails> you dont have other menus killing other menus
<SSNTails> because those other menus don't know what kind of state the menu it is killing is in
<SSNTails> and if that's something stable to do
<Charybdizs> yeah
<Charybdizs> well that makes sense, but I'm trying to imagine how that might work in a game with many different "States" where there might be a different menu format for each one
<SSNTails> like..?
<Charybdizs> ohhhhh
<Charybdizs> I just got it
<Charybdizs> nevermind
<SSNTails> lol whaat
<Charybdizs> so let me get this straight
<Charybdizs> in a system like that, you'd ALWAYS be dealing with an active queue of menus, you'd just have a bunch that all inherit from the basic Form type. Whenever the menu queue is empty, it simply does nothing because there's nothing to do anything WITH. But when a menu is activated, that queue fills and it begins iterating over everthing in it...
<Charybdizs> sorry if I'm confusing. My programming experience is nearly all self taught so I'm not up on a lot of the lingo and usually find my own ways to describe things
<SSNTails> yeah, sort of
<SSNTails> np, i self taught myself too
<SSNTails> for years i was using pointers and not knowing what they were!
<Charybdizs> I invented a type of component based programming all on my own and just last week learned that it's close to an actual practice
<SSNTails> hahahaha
<Charybdizs> So moving on from menus and into more complex situations, like the difference between tetris and an FPS though, you might be dealing with two things that are significantly different from each other and wouldn't be best merged into variants of one loose class type, I think
<SSNTails> Wizard2 does use game states, kind of in a doom-like way
<Charybdizs> You know what, lemme be more specific
<SSNTails> if GameState::NONE, then it only runs the menu system, which relies on that queue of menus
<SSNTails> GameState::LEVEL will run the world functions
<SSNTails> and then run the menu on top
<SSNTails> the HUD itself on top of the world system is also its own menu queue
<SSNTails> and on top of EVERYTHING there is an additional menu queue (the overlay)
<SSNTails> in reality, the world state could become a 'control'
<SSNTails> and put into a menu form
<Charybdizs> I'm designing a turn based strategy a lot along the lines of advance wars and all that. It operates on a 3d field though, and levels are initially made out of blocks of different types, e.g., stone, dirt, water, pavement
<SSNTails> (then you could have multiple worlds at one time.. hah!)
<SSNTails> yeah, i remember you talking a bit about this
<Charybdizs> I have a large amount of the api for the actual levels completed
<Charybdizs> but the confusion
<Charybdizs> is coming in the complete separation between having a playfield where the player moves around their units, having animated battle cutscenes, and having a small overworld area which operates nothing like a turn based strategy
<Charybdizs> and then of course
<Charybdizs> loading and unloading the proper resources for these
<Charybdizs> at the correct times
<Charybdizs> almost none of those features will share any significant code
<SSNTails> i would stuff each part's state into a class
<SSNTails> so in C#...
<SSNTails> I would create an interface
<SSNTails> public interface GameState {
<SSNTails> and define these functions:
<SSNTails> Initialize();
<SSNTails> Update();
<SSNTails> Shutdown();
<SSNTails> }
<SSNTails> then your BattleCutscene, Overworld, etc. classes all inherit from this GameState
<SSNTails> public class OverworldState : IGameState
<SSNTails> (put an I in front of GameState because it's an interface, not a class)
<SSNTails> yes, it takes awhile to wrap your head around interfaces
<SSNTails> essentially what you're building is not a real class, but rather defining functions that all classes which inherit from it are required to have
<SSNTails> SO
<SSNTails> in your main game loop area
<Charybdizs> isn't that the same as an abstract class?
<SSNTails> you have a List<IGameState>
<SSNTails> it's VERY similar to C++'s virtual abstract class
<SSNTails> but i dont think an abstract class FORCES you to implement things
<SSNTails> whereas an interface does
<SSNTails> foreach (IGameState state in myGameStateList)
<SSNTails> {
<SSNTails>      state.Update();
<SSNTails> }
<Charybdizs> I know they both exist in C# but I've always used abstracts and haven't been able to figure out the practical differences
<SSNTails> That will call the Update function whether it is a BattleCutscene, Overworld, or whatever
<SSNTails> http://stackoverflow.com/questions/747517/interfaces-vs-abstract-classes
<Charybdizs> "Ability to specify default implementations of methods"
<Charybdizs> ooooh
<Charybdizs> okay
<Charybdizs> this makes sense
<SSNTails> yeah you cant do that with an interface
<SSNTails> (and im not sure you'd WANT to do that in this situation)
<Charybdizs> Hmm, you know what
<Charybdizs> I like
<Charybdizs> wait brb
<SSNTails> some more brain-exploding information: http://stackoverflow.com/questions/56867/interface-vs-base-class
<SSNTails> i gotta sleep. im happy to discuss this more in daylight :)
<Charybdizs> Alright
<Charybdizs> I'll catch you tomorrow then
* SSNTails has quit ()