Having the menus on the player controller is fine, I would also suggest handling the HUD on it. You should use a dedicated HUD class like Jocko suggested and change it on the player controller via ClientSetHUD when the state changes, eg. when you possess a new pawn. Having all UI be centralized on one object (the player controller) has the advantage that it’s easier to keep track of when to hide the HUD because of the menu, when to show the cursor etc. Also I would strongly suggest to not make references from gameplay code to the Menu or HUD, only the other way around. If your AI is waiting for something you do in the menu, let the menu execute a function on the player controller (replicated to the server) which in turn changes a variable on the game mode for example. The AI asks the game mode about the current state and not the UI. In general you will have a lot more readable and maintainable code if you avoid too many cross references, your gameplay should work without the UI. In some cases you may also want to created “manager” classes instead of having crucial code be managed by the UI. For example you could have a manager object for your user settings, the UI is able to read and write the settings on it, you can register a delegate on it from your audio code to change the volume when the setting was changed for example.