This is a pretty basic Game 101 type problem. I want to create multiple 2D screens, such as login, register, create character, select character, etc. Each screen is a full screen presentation of a particular function. Ultimately the player selects a character and enters a level.
So the question is - what is the standard methodology for designing this flow? It appears that the HUD is linked to a widget (via the create widget action at startup) and there doesnt appear to be any easy way to swap through widgets or keep track of which “screen” you are on. I ended up with one level per screen, with each level having its own game mode which in turn links a HUD class and ultimately loads the widget. The widget’s parent is a C++ class that does the stuff - open a socket and make a call to the server, validate the parameters, etc.
This feels very counter-intuitive. It seems there should be an easy way to have a single “level” which manages all this pre-game stuff and then jump into the game once the non-game stuff is complete.
A side effect of this is that it’s hard to standalone debug windows because using the gamestate in “beginplay” doesnt work unless you change the default game state in the project settings each time - painful. So then you end up having to store window related variables elsewhere (game instance?) which is a horrible break of OOP.
None of the tutorials I found demonstrate anything like this - they all show a game window overlaid with some menu or options, etc. There doesn’t seem to be any good design documents on having window systems that flow from one to the other.