Архитектура игры: моделирование различных шагов / типов пользовательского интерфейса - PullRequest
Новая
       6

Архитектура игры: моделирование различных шагов / типов пользовательского интерфейса

4 голосов
/ 11 апреля 2010

Я не занимался разработкой больших игровых проектов, а только развлекался с маленькими игрушечными проектами. Тем не менее, я никогда не находил интуитивно понятный ответ на конкретный вопрос дизайна. А именно, как моделируются различные типы / состояния пользовательского интерфейса в играх? Например. как представлено меню? Чем оно отличается от состояния «игрового мира» (в качестве примера рассмотрим FPS). Как моделируется наложенное меню поверх «игрового мира»?

Давайте представим основной цикл игры. Где игровые состояния вступают в игру? Это простой индивидуальный подход? 

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

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

Или меню и мир представлены где-то на другом логическом уровне и не представлены на этом уровне? (Например, меню - это просто еще одна сущность высокого уровня, например, вход игрока или менеджер врага, равный всем остальным) 

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

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

Ответы [ 2 ]

5 голосов
/ 12 апреля 2010

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

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

Но на самом деле, нет особой необходимости в отдельном игровом состоянии меню. Ваша игра обычно имеет графический интерфейс, с некоторыми видимыми элементами, некоторые невидимыми. Чтобы вызвать меню, вы просто создаете или отображаете элементы, которые вам нужны. Вам также может понадобиться приостановить игру на этом этапе. (Или нет, если это сетевая игра.) Если игра еще не ведется, неважно. Как правило, ваша система будет гораздо менее упрощенной версией этого: 

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

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

Последние 2 этапа можно даже объединить, если ваша система графического интерфейса адекватна.

Хотя я не всегда следую своему собственному совету, я думаю, что редко есть веская причина иметь отличный конечный автомат для игры. Существует небольшое количество объектов, которые существуют в небольшом количестве перестановок, и вам просто нужно обновить и отобразить их все.

0 голосов
/ 12 апреля 2010

Большинство каркасов GUI управляются событиями, то есть: элементы меню (а также кнопки и другие «входные» виджеты) связаны с окном и с объектом слушателя, который вы предоставляете.Фреймворк заботится о вызове метода onAction (или что-то в этом роде) для вашего объекта слушателя всякий раз, когда пользователь нажимает на меню / кнопку.

Вам, как программисту, не нужно писать код, которыйявно проверяет эти элементы меню.

...