Game architecture: modeling various steps / types of user interface

Question

I did not deal with large game development projects, but only with small toy projects. However, I did not find an intuitive answer to a specific design question. Namely, how are different types / states of the user interface in games modeled? For instance. How is the menu presented? How does this differ from the state of the "game world" (for example, use FPS). How is the menu overlaid on the "game world"?

Imagine the main game loop. Where do game states play? Is this a simple approach in each case?

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

Or are menus and the world represented somewhere in another logical layer and not represented at this level? (For example, a menu is another high-level object, for example, a player’s input or an enemy manager, equal to all the 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? Think about it, I don’t know any design patterns related to the game — I believe there are others. Please tell us about them.

Answer 1

The menu in the game is almost the same as the menu in any application - it is a set of GUI elements with behaviors attached to them. This refers to whether you have a specific menu state or not.

There are several reasons why games have different menu states. One of them is that the game menus are dated before we had usable libraries of graphical user interfaces for games, and most of these menus will simply be collections of sprites and some hard-coded routines for processing mouse clicks. Another thing is that games often require very different input processing during the game, which is necessary during the menu, and therefore it is often easier to have completely separate procedures that process them.

But in fact, there is no need for a separate state of the game in the menu. Your game usually has a graphical interface, some visible elements, some invisible. To open the menu, you simply create or display the necessary items. You may also need to pause the game at this point. (Or not, if it works on the network.) If the game is not already started, it doesn’t 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 steps can be combined if your GUI system is adequate.

Although I do not always follow my advice, I think that there is rarely a good reason to have an excellent top-level state machine for the game. There are a small number of objects that exist in a small number of permutations, and you just need to update and display them all.

Answer 2

Most graphical interfaces are event-based, that is: Menu items (as well as buttons and other "input widgets") are associated with the window and with the recipient object that you provide. Framework takes care of calling the onAction method (or something like this) in your listener object whenever the user clicks on the menu button /.

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