Как обстоят дела с графическим интерфейсом и игровой программой по сравнению с веб-программами?

Question

Я уже некоторое время занимаюсь разработкой веб-приложений и погрузился в разработку GUI и приложений для игр.

В веб-приложении (php для меня) к файлу делается запрос, в этот файл входят все необходимые файлы для обработки информации в памяти, а затем поток идет сверху вниз для каждого запроса. (В основном)

Я знаю, что для игр действие происходит внутри игрового цикла, но как все различные элементы игры объединены в один цикл (система меню, графический интерфейс, загрузка ресурсов и трехмерный мир) с постоянной загрузкой и разгрузка определенных вещей.

То же самое для программ с графическим интерфейсом, я полагаю, что есть "цикл приложений" некоторых видов.

Являются ли большинство элементов вызываемыми в память, а затем доступными, связываются ли элементы и загружаются ли в память при необходимости?

Что помогло мне быстрее разрабатывать веб-приложения, так это то, что когда я понял ход выполнения программы, он не должен быть подробным, просто общая идея или псевдокод.

Answer 1

Во всех них почти всегда есть петля - но это не то, о чем вы склонны думать в течение большей части своей разработки.

Если вы сделаете шаг назад, ваши веб-приложения будут основаны на цикле - цикл accept() веб-сервера:

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

.. но как веб-разработчик вы защищены от этого и пишете код, «управляемый событиями» - «когда кто-то запрашивает этот URL, сделайте это».

GUI также управляются событиями, и события также где-то обнаруживаются циклом:

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

Но разработчику GUI не нужно много думать о цикле. Они пишут «когда здесь происходит щелчок мышью, сделайте это».

Игры, опять то же самое. Кто-то должен написать цикл:

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

... в то время как другой код написан в более управляемом событиями стиле: «когда объект пули совпадает с этим объектом, инициируйте событие взрыва».

Answer 2

Что касается программирования игр, я был просто увлеченным человеком, однако обычно я так и делал:

У меня был объект, который представлял очень общую концепцию «сцены» в игре. Все различные основные разделы игры взяты из этого объекта Scene. Сцена действительно может быть чем угодно, в зависимости от типа игры. В любом случае, каждая более конкретная сцена, полученная из сцены, имеет процедуру для загрузки всех необходимых элементов для этой сцены.

Когда игра должна была менять сцены, указатель на активную сцену был установлен на новую сцену, которая затем загружала бы все необходимые ей объекты.

Общий объект Scene имел виртуальные функции, такие как Load, Draw и Logic, которые вызывались в определенное время в игровом цикле из указателя активной сцены. У каждой конкретной сцены были свои способы реализации этих методов.

Я не знаю, так ли это должно быть или нет, но для меня это был очень простой способ контролировать поток вещей. Концепция сцены также позволяет легко хранить несколько сцен в виде коллекций. Поскольку несколько указателей сцен хранятся в одной и той же стопке, сцены могут сохраняться в резерве и сохранять свое полное состояние при возврате к ним или даже выполнять такие операции, как тусклый, но продолжать рисовать, пока активная сцена перерисовывает их как наложение. сортов.

Так или иначе, если вы делаете это так, это не совсем как веб-страница, но я думаю, если вы думаете об этом правильно, это достаточно похоже.

Answer 3

Для приложений и, в меньшей степени, для игр программное обеспечение ориентировано на события. Пользователь «что-то» делает с помощью клавиатуры или мыши, и это событие отправляется остальной части программного обеспечения.

В играх важен игровой цикл, поскольку он ориентирован на обработку экрана и состояния игры. Многие игры нуждаются в производительности в реальном времени. Благодаря современному API 3D-графики большая часть обработки экрана может быть перенесена на графический процессор. Однако игровое состояние отслеживается основным циклом. Большая часть усилий команды для игры направлена ​​на то, чтобы сделать цикл очень плавным.

Для применения обычно тяжелая обработка порождается в потоке. Это сложный вопрос из-за проблем, связанных с двумя вещами, пытающимися получить доступ к одним и тем же данным. Есть целые книги на эту тему.

Для приложений последовательность:

1. пользователь выполняет X, X и связанная с ним информация (например, координаты X, Y) отправляется в UI_Controller.
2. Пользовательский интерфейс решает, какую команду выполнить.
3. Команда выполнена.
4. Модель / данные изменены.
5. Команда указывает UI_Controller обновлять различные области пользовательского интерфейса.
6. UI_Controller перерисовывает пользовательский интерфейс.
7. Команда возвращается.
8. Приложение ожидает следующего события.

Есть несколько вариантов этого. Модель может позволить слушателям ждать изменений в данных. Когда данные слушатель выполняет и перерисовывает пользовательский интерфейс.