Hi tas,
The state managed by the GameInstance is only relevant to the local player - other players are only connected to the game while actually in the gameplay map. In the menu screens, the local game process is only aware of the one player currently navigating the menu. Now, if you had a game that supported splitscreen or similar functionality with multiple local players, and these players could navigate the UI independently of each other, then yes, you’d want to store some state per player.
Admittedly, using the PlayerController at index 0 here is probably not best practice in general. As above, it works in case because while the player is in the menus, he’s the only one connected to the game.
The reason I say it’s not best practice in general is for two reasons. One, servers will create an instance of a PlayerController for each client that connects. On listen servers, there’s a good index 0 will refer to the local player’s controller in practice, but that should not be relied upon. On clients, works in practice because only the PlayerControllers for the local players are replicated to them. The second reason is related - for games that support splitscreen or similar functionality, there will be multiple PlayerControllers that each represent one of the local players, and in case, you may want to associate widgets with particular local players. If the widgets are created in the PlayerController class, remember that the server creates a controller for each client that connects - so consider adding logic to prevent creating widgets for non-local players.