Game architecture: modeling different steps/types of UI

Question

I have not done any large game development projects, only messed around with little toy projects. However, I never found an intuitive answer to a specific design question. Namely, how are different types/states of UI modeled in games? E.g. how is a menu represented? How is it different from a "game world" state (let's use an FPS as an example). How is an overlaid menu on top of a "game world" modeled?

Let's imagine the main loop of a game. Where do the game states come into play? It it a simple case-by-case approach?

if (menu.IsEnabled) menu.Process(elapsedTime);
if (world.IsEnabled) world.Process(elapsedTime);

if (menu.IsVisible) menu.Draw();
if (world.IsVisible) world.Draw();

Or are menu and world represented somewhere in a different logic layer and not represented at this level? (E.g. a menu is just another high-level entity like e.g. player input or enemy manager, equal to all others)

foreach (var entity in game.HighLevelEntities) entity.Process(elapsedTime);
foreach (var entity in game.HighLevelEntities) entity.Draw(elapsedTime);

Are there well-known design patterns for this? Come to think of it, I don't know any game-specific design patterns - I assume there are others, as well? Please tell me about them.

Answer 1

Most GUI frameworks are event driven, that is: Menu elements (as well as buttons and other "input" widgets) are associated with a window and with a listener object that you provide. The framework takes care of calling the onAction (or something like that) method on your listener object whenever the user clicks on the menu/button.

You, as a programmer, does not need to write code that explicitly checks these menu elements.

Answer 2

A menu in a game is pretty much the same as a menu in any application - it's a collection of GUI elements with behaviours attached to them. This applies whether you have a distinct menu state or not.

There are several reasons why games tend to have distinct menu states. One is because game menus date back to before we had usable GUI libraries for games and most of these menus would just be collections of sprites and some hard-coded routines to handle the mouse clicks. Another is because games often require very different input handling during the game to what is needed during the menu and therefore it's often easier to have totally separate routines handling these.

But really, there's little need for a distinct menu game state. Your game typically has a GUI, with some elements visible, some invisible. To bring up a menu you simply create or display the elements you need. You may also need to pause the game at that point. (Or not, if it's networked play.) If there's no game in progress yet, no matter. Typically, your system will be a much less simplified version of this:

// update
world.update()
gui.update()

// render
world.render3D()
world.render2D_overlays()
gui.render()

The last 2 stages could even be combined, if your GUI system is adequate.

Although I don't always follow my own advice, I think there's rarely a good reason to have a distinct top-level state machine for a game. There are a small number of objects which exist in a small number of permutations and you just have to update and render them all.