# Should UI be part of the game-loop?

I can't really find a good answer to this anywhere, I have never worked on games in a proffessional environment and I am wondering; Do these games render their UI in the main game-loop?

That is, do they render loading-screen, menu-screen, text-dialogs with running text, ingame UI (direction arrows for example) in the main game loop? that is the same game-loop they use to update and render the actual game-play, meaning only one activity is used, and the game-loop runs from the moment the app starts until it exits.

I'm having a hard time making my menu because I want to animate the buttons, but when I have the menu in my main game-loop and I for example press the "start game"-button, the game starts right away before the buttons animation is played (supposed to shrink), is this just done adding like a timer for delay or something like that (like in example below)? Feels so ugly.

Ugly pseudo code:

if(startButton gets pressed){
start button animation;
start 1 second timer;
timer finished -> start game;
}


EDIT: I'm building my game for ios and Android using LibGdx Java, but I guess this question is universal so that might not be relevent.

• I can't speak from industry experience, but a common approach appears to be using a stack to simplify the management of menus.
– Alex
May 1 '15 at 13:58
• I can see the benefit of that if you have many states and/or menus, I hate games like that though, shouldnt take 25 clicks to get from one level to the next ^^ Thanks for the comment Alex! May 1 '15 at 14:13
• Using states can still be beneficial even if there are only a few of them (e.g. main menu, game screen, and pause screen). The advantage is they can be easily switched between, and it separates the logic intuitively. This would mean the rendering would be separate for the various 'screens' (I would expect UI elements to be included in the 'game render-loop' though).
– Alex
May 1 '15 at 14:26
• @Alex sure, I use game states but only running and paused atm. Since each "screen" (game, menu, level-selector) handles it's own rendering I dont really need any more states. I guess you could say I use several screens instead of several game states, I just find that this way my code is much cleaner. May 1 '15 at 16:54
• Like others say, Yes use states and continue ticking, letting the action unfold in an orderly and controlled fashion. ...And just to reiterate your own intuition: Yes, do NOT just throw in a delay or timer. AYup. May 1 '15 at 16:55

Yes, generally, games are a single main loop.

Games in Java may have a separate main loop for each menu/screen/mode due to Java's idioms, but that of course does not solve your animation wait problem.

For things like the problem you are running into, consider using events. e.g., when your animation system finishes playing an animation, it can send out an event indicating that the animation is done. The menu UI listens for this event and only transitions to the game state at that moment. That lets the animation play, plus it means that the animation can be changed (i.e. get a new duration) and the UI will properly adjust how long it waits before moving into the game state.

If events don't work well for you in this case, you could also just poll the animation state. Something like:

class MenuState {
_startAnimation = null;

void Update() {
if(IsPressed(StartButton))
_startAnimation = PlayStartAnimation();

if(_startAnimation && _startAnimation->IsFinished())
EnterGameState();
}
}


That gives you (in this case) most of the advantages of the event systems. Most games will end up using a mixture of events and polling (depending on situation), so familiarizing yourself with both approaches is a good idea.