Official RPG Codex Discord Server

  1. Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
    Dismiss Notice

Managing Game States

Discussion in 'Codex Workshop' started by desocupado, Oct 13, 2015.

  1. desocupado Magister

    desocupado
    Joined:
    Nov 17, 2008
    Messages:
    1,802
    So, let's say you're making your game and stuffies, and you make a "main menu" game state with a splash screen, new game button, load game button, quit button. You also have your "game screen" game state, with the map, the ui, etc.

    What is the best way to make the change from the "main menu" game state to the "game screen" game state?

    I mean, I can setup so that clicking the new game button would free the memory from the buttons and splash screen and call the "game screen" state, but that still would be from within the "main menu" state. That doesn't seem like a good/elegant solution.

    I've seen a tutorial suggest that I keep my game states in a stack, inside a vector, first in, last out. I would need a game state manager class, which is not a problem, but how is the ideal solution to make the "main menu" state tell the game state manager class "Hey, I'm done, put a game screen inside the stack and start() it, I'll sleep until he's done"?

    I hope I'm not being confusing. I want to know how to call the next game state after destroying the current game state, the information on which game state to call being inside the destroyed game state. What is the more efficient/elegant way of passing this information to the game state manager class?
     
    ^ Top  
  2. potatojohn Arcane

    potatojohn
    Joined:
    Jan 2, 2012
    Messages:
    2,354
    Here's how I did it: I had a UI class that contained (pointers to) widgets. The global game state had a pointer to the current UI

    The main loop called update(), draw(), etc on the current UI pointer

    When I want to switch to a different UI I just change the pointer, no need to create or destroy anything.

    https://github.com/dvolk/project_x/blob/master/src/ui.h
    https://github.com/dvolk/project_x/blob/master/src/main.cpp#L190
    https://github.com/dvolk/project_x/blob/master/src/main.cpp#L11747
    https://github.com/dvolk/project_x/blob/master/src/main.cpp#L9798
     
    ^ Top  
  3. 28.8bps Modem Prophet

    28.8bps Modem
    Joined:
    Jan 15, 2014
    Messages:
    302
    Location:
    The Internet, Circa 1993
    A stack is usually the right way to go. I'd suggest treating it explicitly like a program stack, where your game states are "functions" each taking a parameter and returning a value.

    For example, the main menu can launch a game a number of ways, it can start a new game, continue an explicit save game, or resume from the last saved game. You'd still push the same state on to the stack, but they'd be parametrised differently. Similarly, with a map transition, the map that you just left would return down the stack to the loader state with parameter information on the next map to load and other variables that aren't loaded from saved game state like where the player character/party should be spawned on the next map, etc. The loader would then throw up a loading screen, do the map load, push the map state on to the stack and pass the parameters to it.
     
    ^ Top  
  4. flabbyjack Arcane

    flabbyjack
    Joined:
    Jul 15, 2004
    Messages:
    2,541
    Location:
    the area around my keyboard
    game.state = 'main menu'
    game.state = 'loading'

    <fin>
     
    ^ Top  
  5. Alex Arcane

    Alex
    Joined:
    Jun 14, 2007
    Messages:
    6,592
    Location:
    São Paulo - Brasil
    Deso, I am not sure why you want to keep track of the game state manually. Assuming you have a graphical library capable of handing events, that is pretty much all you need. For instance, suppose you are on the main screen and the user clicks "new game". The code associated with the new game button will create a new gameworld, associate a new game screen to it, decouple the window from the main game screen, delete the objects there and finally associate the new game screen with the window. This code isn't part of the new game screen. It exists outside of it, though it is referenced from it.

    I think keeping your screens on a stack would only make sense if you want to be able to move quickly (without loading) from one to another.
     
    ^ Top  
  6. desocupado Magister

    desocupado
    Joined:
    Nov 17, 2008
    Messages:
    1,802
    Well, cause while the main_menu state needs only a pointer to the gui/window objects, the game_screen object needs those, plus the entities vector and the map (which main_menu can't provide), and the next game state has different arguments as well, and so on and so forth. So it's better to call them from one manager class Game, which has all of that stuff, instead of making shit global, or passing one ton of un-needed arguments to every game_state object, only so they can pass them forth.
     
    ^ Top  
  7. Hirato Purse-Owner Patron

    Hirato
    Joined:
    Oct 16, 2010
    Messages:
    3,732
    Location:
    Australia
    Codex 2012 Codex USB, 2014 Shadorwun: Hong Kong
    Depends on your game.

    Most older games would run different code paths if they're in the main menu or not.
    I use this approach personally, and in my case it boils down to two states, "is in game" and "is not in game". In the former case the gameworld is drawn and in the latter just a background is drawn instead.

    Most modern games treat the main menu as a separate game in itself that then loads up the proper game.
    You can pretty much safely assume that this approach was used if you can see the game world, game models looping their animations in the background, or the game playing out in the background with dumb AI.


    In the vast majority of cases, the loading screen isn't really a state, It's rather noise you draw while you wait for the loading to finish.
    For older games, which are basically singlethreaded, they loaded the items one by one and drew the occasional frame with an updated progress bar.
    Due to this simple nature, these games have no 'loading state' they're simply loading.

    More modern games do the loading in the background in a separate thread, so it can continue playing the game or do other things while things are actually loading.
    Generally you get a thread that draws a very smoothly animated loading screen while waiting on the loading thread to finish, this isn't a change of state either.

    Interactive loading screens on the other hand almost always have a change of state, as it either changes controls, disables certain things, or involves a little minigame.



    It's hard to give a general answer as lots of it boils down to implementation details of the game logic, and what supports that game logic.
     
    • Brofist Brofist x 1
    ^ Top  
  8. DraQ Prestigious Gentleman Arcane

    DraQ
    Joined:
    Oct 24, 2007
    Messages:
    32,825
    Location:
    Chrząszczyżewoszyce, powiat Łękołody
    A flexible solution would be to not have a menu state.
    Just a main menu that is overlaid over the game screen like all the other menus, be them inventory, stat screen and so on

    This is how most of the FPS games I can think of and games like Morrowind seem to do it.
    You don't really need your menu to handle any sort of logic on its own, just capture input and send it to the underlying logic.
    This way you don't have the separate main menu and in-game menu, the main menu is just your general purpose menu overlaid over dummy game state made to show up as blank screen, some background graphics, animation or an "attract mode" which is usually a prerecorded demo.
     
    ^ Top  

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.