Урок 2. Общие принципы работы игровой программы

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

Дизайн и отрисовка.

Программа запущена. Что мы должны увидеть прежде всего? Героя? Непонятно, где его показывать. Монстров, ловушки? Эти объекты, очевидно, тоже не удастся изобразить на трапе, пока не будет нарисован ключевой элемент - карта локации, нашего игрового мира. А нот эту карту можно отобразить, даже если на ней первоначально нет никаких предметов и героев.

После того, как карта показана, на ней можно отображать предметы и живых существ. Тайлы карты правильно выводить не в виде прозрачных спрайтов (так как под ними больше ничего нет), а просто в виде небольших "сплошных" квадратов, фрагментов изображений. А вот предметы и фигурки монстров надо будет показывать на тайлах уже в прозрачном виде, как бы положенных на тайлы сверху. Причем сначала желательно "положить" сначала предметы, а потом монстров и героя, чтобы создавалась видимость нахождения героя на тайле с предметом, а не наоборот.

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

Еще один важный вопрос заключается в том, как часто выводить карту со всеми расположенными на ней объектами. Можно, конечно, оптимизировать различные аспекты графического движка - например, при перемещении героя перерисовывать не всю карту, а только начальный и конечный тайлы перемещения. Однако по мере усложнения логики программы такая перерисовка тоже может усложниться - на освобожденный таил могут зайти монстры, возникнуть брошенные предметы и т. д. Поэтому договоримся после каждого шага героя перерисовывать всю карту (точнее, всю видимую часть). На современных компьютерах эта процедура не будет занимать много времени и станет незаметной для глаза. Такой подход, кстати, реализуется при использовании графической библиотеки DirectX, формирующей образ всего экрана в буфере и перерисовывающий его десятки раз в секунду. Мы не будем привязываться к полноэкранному режиму - в частности, потому, что для управления нашей программой, где основные события будут развиваться в пошаговом режиме, удобнее и проще использовать готовые элементы управления Windows. Хотя, отметим, потенциально архитектура программы позволит переносить ее без особых усилий на любые графические движки! Управление программой

Хорошие ролевые игры обязательно содержат удобный клавиатурный интерфейс. Мы тоже сделаем управление программой на основе клавиатуры, а дополнение игры возможностью управления с помощью мыши оставляем подписчикам в качестве дополнительного задания. Такой интерфейс удобен тем, что позволяет очень быстро выполнять множество игровых действий - со скоростью, недостижимой через мышиное управление. Кроме того, он достаточно точно отвечает концепции игры, ориентированной на одного главного героя, не нуждающегося в контроле над внешними объектами. Отказ от мышки будет полезен и с другой точки зрения - ведь мы решили создавать игру сразу для нескольких платформ, и не исключено, что мышка будет доступна далеко не везде (нет ее например на компьютерах и интеллектуальных смартфонах - стремительно набирающих популярность "наладонниках"). Но простейшим общедоступным вариантом будут операционные системы ДОС и Windows. Причем в ДОС-е мы постараемся реализовать программу в текстовом режиме, а в Windows -в графическом (конечно на основе одного и того же исходного программного кода). В идеале неплохо было бы также создать переносимый мышиный интерфейс. Уважаемые читатели могут попробовать сделать это самостоятельно.

Игры-стратегии, особенно проходимые в масштабе реального времени без мышиного интерфейса конечно немыслимы. Можно вспомнить первую "Цивилизацию" - но она была пошаговой и не требовала от пользователя оперативного управления большими армиями однообразных юиитов.

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

Эта концепция впрочем уже давно предложена видными компьютерными гуру. Она называется событийно-ориентированным программированием. Управляющий модуль программы ни и нем обычно находится в состоянии ожидания, а определенные действия пользователя трактуются как события, прерывающие это ожидание. Каждое регистрируемое событие должно быть программно обработано. Например, человек нажимает клавишу F1, программа фиксирует факт нажатия клавиши, формирует событие "нажата клавиша" и передает его на обработку управляющему блоку. Там вызывается функция с параметром, равным значению клавиши (F1).

  Такой подход оптимален тем, что допускает легкую реализацию как в ДОС, так и в Windows (которая сама построена на этом принципе) и большинстве других операционных систем, в том числе  Linux/Unix.