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.
You surely do not need a level for each widget.
There are many ways to this properly. One way is to keep record of the actul widget (in a variable) and simply destroy and create a new one (and add to viewport/canvas slo) as your flow goes forth and back. I usually use playercontroller to initiate the HUD.
You can also play with widgetswitcher widget I like to use it for flow-type things.
Widget Switcher seems really good for this.
Here is a link to a tutorial video (the channel has some awesome tutorials overall) :
Alternatively you could make one “MainMenuWidget” widget without any visible content (just a blank widget), which creates and holds references to the different subscreen widgets as child widgets (“MainMenu_Options_Widget”, “MainMenu_Login_Widget”, etc), and depending on what button you push you enable/disable visibility of the subscreen widgets.
Another possibility is, again, making one “MainMenuWidget” widget without any visible content, but instead of creating all widgets at once and individually toggling their visibility, you create and “remove from parent” (aka destroy) menu widgets depending on button pushes.
Personally, i like the first and second one the most, the third one (creating and destroying widgets) seems kind of unneccessary create/destroy-work for the game.
So Widget Switcher hacks through this ok - becomes really unmanageable after 5 or 6 windows though. Also you have to enforce OOP yourself with some kind of naming convention for each control. For example if you have a close button on 3 different screens you have to do cmdWndLoginClose, cmdWndRegisterClose, etc. The BP behind it gets super messy fast. I suppose it’s a hack to get through this, but it really breaks all of the OOP rules.
Dynamic creation could work but then you lose all the utility of the drag and drop designer; have to sort of write your own layout language so it works on multiple layouts/resolution.
Feel like this is an overlooked area in engine. Anyway thanks for the ideas will forge ahead with the tools I have!
