I’ve been thinking about getting a simple template project together for my students so that it handles the typical main-menu to game flow in an organized way and wanted to get your thoughts.
Normally in my projects I have a state machine class that is held in the main game instance. That state machine has the usual FSM functionality (set state, states with enter/update/exit etc). I then bind UI controls to specific states such that as the game progresses through the flow, the appropriate transitions happen on the required UI controls at the right time.
What this means in practice is that the state machine itself needs to be persistent. Ideally I’d like some simple editing interface (tree view based editing would work fine because it usually ends up as a HFSM) to setup states and associate UI with states etc.
I guess my main question is about persistence and level loading. If you look at shootergame, it has an example of this kind of thing. But I really don’t want my students to have to do UI in C++, when blueprint is clearly a better option for UI design.
How do you guys go about structuring a game flow setup?
I’m assuming that you use persistent empty level for all UI, then use openlevel during the game to actually determine the level? How do you then unload the level? How does this all tally with things like level streaming? Is there a better way of setting things up so that its easy to just get straight into a test level etc?
I know that gameinstance is a useful place to store the FSM for example, but I don’t think its quite right for the UI to be stored there is it? I mean the UI needs to be loaded when you start the game, so I envision that as the only persistent level, then everything else is loaded from levels at the correct time.
I was under the impression that Epic were going to release an updated shootergame with all the UI done in UMG, but I guess I might have been mistaken. Would be a useful example to see a full game loop (menu->game->end->menu) done the “correct” way at some point.
Depends on what the “correct” way is
I have been using PlayerController to to add/remove a main menu from viewpoint, only keeping a reference to the menu when it is visible.
At the moment this means the menu is created from scratch every time, which was fine originally when the menu was very light weight, but not so much now that it has matured.
Kris - I am doing the exact same thing with the menu… what is the alternative to creating it at Begin Play from the player controller? (Or rather, I create it from the Game Instance)
I have a ToggleMenu action that will create a main menu manager and add that to the viewpoint when pressed, then remove it when pressed again.
The ToggleMenu action is only used as a input for a the Blueprint and doesn’t actually do anything in C++.
Each screen is a child of the main menu manager and is normally set to be collapsed, only becoming self hit test invisible when told to be the currently selected screen.
The more I add to the menu, the less appealing this setup is as there can be some noticable delay.
I will most likely change things so each screen is only created when you press the button associated with the screen.
