How is GUI and Game Program Flow compared to Web programs

Question

I've been developing Web applications for a while now and have dipped my toe into GUI and Game application development.

In the web application (php for me), a request is made to the file, that file includes all the necessary files to process the info into memory, then the flow is from Top to Bottom for each request. (mainly)

I know that for Games the action happens within the Game Loop, but how are all the different elements of a game layered into that single loop (menu system, gui, loading of assets and the 3d world) with the constant loading and unloading of certain things.

Same for GUI programs, i believe there's an "application loop" of some sorts.

Are most of the items called into memory and then accessed, are the items linked in and loaded into memory when needed?

What helped me develop web applications faster is when i understood the flow of the program, it doesn't have to be detailed, just the general idea or pseudo code.

Answer 1

For applications and to a lesser extent Games the software is event driven. The user does "something" with the keyboard or mouse and that event is sent to the rest of the software.

In Games the Game Loop is important because is focused on processing the screen and the game state. With many Games needing real time performance. With modern 3D Graphics API much of the screen processing is able to be dumped onto the GPU. However the Game State is tracked by the main loop. Much of the effort of a team for a game is focused on making the processing of the loop very smooth.

For application typically heavy processing is spawned on onto a thread. It is a complex subject because of the issues surrounding two things trying to access the same data. There are whole books on the subject.

For applications the sequence is

1. user does X, X and associated information (like X,Y coordinates) is sent to the UI_Controller.
2. The UI decides which command to execute.
3. The Command is Executed.
4. The model/data is modified.
5. The Command tells the UI_Controller to update various areas of the UI.
6. The UI_Controller redraws the UI.
7. The Command returns.
8. The Application waits for the next event.

There are several variants of this. The model can allow listeners to wait for changes in the data. When the data the listener execute and redraws the UI.

Answer 2

There's almost always a loop in all of these - but it's not something you would tend to think about during most of your development.

If you take a step back, your web applications are based around a loop - the Web Server's accept() loop:

while(listening) {
     get a socket connection;
     handle it;
}

.. but as a Web developer, you're shielded from that, and write 'event driven' code -- 'when someone requests this URL, do this'.

GUIs are also event driven, and the events are also detected by a loop somewhere:

while(running) {
    get mouse/keyboard/whatever event
    handle it
}

But a GUI developer doesn't need to think about the loop much. They write 'when a mouse click occurs here, do this'.

Games, again the same. Someone has to write a loop:

while(game is in progress) {
    invoke every game object's 'move one frame' method;
    poll for an input event;
}

... while other code is written in a more event-driven style: 'when a bullet object coincides with this object, trigger an explosion event'.

Answer 3

As far as game programming went I was merely a hobbyist, however this is what I usually did:

I had an object that represented a very generic concept of a "Scene" in the game. All the different major sections of the game derived from this Scene object. A scene could really be anything, depending on what type of game it is. Anyway, each more specific scene that derived from scene had a procedure to Load all of the necessary elements for that scene.

When the game was to change scenes, the pointer to the active scene was set to a new scene, which would then load all of its needed objects.

The generic Scene object had virtual functions such as Load, Draw, and Logic that were called at particular times in the game loop from the active scene pointer. Every specific scene had its own ways of implementing these methods.

I don't know if that's how it's supposed to be done or not, but it was a very easy way for me to control the flow of things. The scene concept also made it easy to store multiple scenes as collections. With multiple scene pointers stored in a stack of sorts at one time, scenes could be stored in reserve and maintain their full state when returned to, or even do things like dim but to continue to draw while the active scene drew over them as an overlay of sorts.

So anyway, if you do it like that it's not precisely like a web page but I guess if you think about it the right way it's similar enough.