Компьютерные игры. Как это делается

       

Освещение


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

Панно Икельс (Pancho Eekels), один из дизайнеров у ровней, коллега Клиффа Блежински, сумел создать хорошо освещенное, красочное и в то же время мрачное помещение. Скриншот из игры Unreal Tournament. (Использовано с разрешения Клиффа Блежински.)

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


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

В программировании информация часто хранится в виде массивов, то есть строк данных. Нередко попытка обращения к областям памяти находящимся за пределами массивов, вызывает общий сбой Windows - General Protection Fault (GPF). Например, если массив содержит только пять элементов, а программа попытается получить доступ к восьмому, вы увидите на экране сообщение о GPF. Чтобы застраховать себя от подобных ошибок, обратите внимание на следующую программу.

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

template <class Entry> class Array

{

private:

Entry *pEntry;

int iSize;

Далее шаблон содержит внутренние компоненты для добавления (размещения) и удаления записей массива, а также компоненты для доступа к массиву, подобные приведенному ниже:

public:

// Обеспечивает доступ к записям массива...

Entry &operator [](const int ilndex) const

{

Assert(ilndex >= 0 && ilndex < iSize);

return pEntry[ilndex];

}

Функция Assert очень важна, так как она вызывает ошибку отладки, если значение выражения-аргумента Assert равно FALSE. Этот небольшой фрагмент программы спас нас от такого количества ошибок, что я просто не представляю, что бы мы без него делали. Наш макрос Assert выглядит примерно так:

// Режим отладки:

#if defined(_DEBUG)

extern BOOL MyAssertFunc(BOOL, int, char *};

#define NatBreakf) { _asm { int 3 } }

// Утверждает, что значение ехр - истина.

#define Assert(ехр) \

if (MyAssertFunc((int)(exp),__LINE__,__FILE__)) \

NatBreak();

// Режим без отладки:

#else

#define Assert(exp)



#endif // _DEBUG

При окончательной сборке все макросы Assert исключаются из компиляции. При сборке для отладки функция MyAssertFunc включается в библиотеку. Функция вычисляет первый аргумент и выводит окно сообщения, указывающее строку и файл, где сработало утверждение (последние два аргумента). После этого программист может принять решение продолжить или прервать выполнение. При выборе прерывания функция возвращает значение TRUE, и инструкция int 3 приведет к остановке отладчика на строке макроса Assert.

Узнать все о проекте Drakan вы сможете, заглянув на сайт www.psygnosis.com/drakan/.

Ричард Моу (Richard Moe), Humongous Entertainment

Ричард Моу, сотрудник компании Humongous Entertainment, привык выступать в самых разных амплуа: от руководителя проекта до (помимо прочих обязанностей) инженера-программиста. Все игры Humongous пишутся на собственном языке SCUMM, который был разработан соучредителем компании Роном Гилбертом (Ron Gilbert). Вот лишь некоторые проекты, отмеченные вниманием дизайнера и программиста Ричарда Моу (в хронологическом порядке): Junior Field Trips: Let's Explore the Airport, Pajama Sam in There's No Need to Hide When It's Dark Outside, Backyard Baseball и Putt-Putt Enters the Race.

Ричард утверждает, что каждая игра ставит перед дизайнером и программистом собственный набор проблем. Ниже он приводит примеры из своей практики.

При создании детских игр самое проблематичное - определиться со сложностью, чтобы игра получилась интересной и легкой как для четырехлетнего, так и для восьмилетнего ребенка. Очевидно, что уровень мастерства игроков в пределах этого возрастного диапазона существенно отличается. Например, в Pajama Sam входит простая игра типа крестиков-ноликов, Cheese and Crackers («Сыр и печенье»). Для игры используются доски трех размеров: 3x3, 5x5 и 7x7. Доска 3x3 - это классические крестики-нолики, три знака в ряд выигрывают. На досках 5x5 и 7x7 для выигрыша требуется поставить в ряд соответственно четыре или пять знаков. Легко понять, что первый из трех вариантов самый простой (меньше комбинаций), а остальные последовательно сложнее.


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

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

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

Должен ли программист разбираться в других областях «игростроения»?

Бюджет - страшная вещь. Действительно, по ходу проекта программисту часто приходится становиться мастером на все руки - что делать, специалистов не хватает. В других случаях возникающая проблема является уникальной для игры и используемого движка. Я не могу поручить человеку, хорошо знающему Си++, написать подпрограмму, которую можно будет использовать в моей игре, основанной на языке SCUMM. В этом случае незнакомый со спецификой инструментария программист может не справиться с заданием (чаще всего именно так и происходит).


К слову, совсем недавно я столкнулся с подобной проблемой во время работы над Putt-Putt Enters the Race. В конце игры игрок должен провести свой автомобильчик (Putt-Putt) по псевдотрехмерной трассе. Чтобы все это правильно работало, я должен был отслеживать объекты в трехмерном виде. У меня не было практически никакого опыта в трехмерных преобразованиях, а рядом, увы, не оказалось ни одного человека, который мог бы прийти мне на помощь. В итоге ваш покорный слуга был вынужден делать все самостоятельно. К счастью, у меня есть несколько знакомых специалистов, и результаты оказались удовлетворительными. Конечно, это не Gran Turismo, но давайте вспомним основной вопрос: я понял, что мою аудиторию (дети 3-8 лет) не волнует реальность физических моделей и трехмерная визуализация в реальном времени. Вместо этого я поместил несколько забавно выглядящих уток, которые должны были крякать и улетать, если вы подъезжали к ним слишком близко.

А как лучше всего научиться программированию? «Зажмите нос и ныряйте прямо на самую глубину, - советует Ричард. - Начните с простого - игры вроде Minesweeper или тетриса. Или с клона Space Invaders. Еще немного, и вы доберетесь до трехмерных экшен-стратегий от третьего лица в реальном времени».

Курт Пфайфер (Kurt Pfeifer), Cavedog

Cavedog Entertainment - компания-партнер Humongous Entertainment, разработавшая в свое время стратегическую игру Total Annihilation, которая имела умопомрачительные продажи и была отмечена невероятным количеством наград со всего мира. Знакомьтесь: Курт Пфайфер, один из авторов Total Annihilation. Кроме того, в его послужном списке Microsoft Soccer, Powerslave, DinoPark Tycoon и Magic School Bus Across the Solar System, а также перенос Duke Nukem 3D на приставку Sega Saturn. На момент написания книги он занимал должность ведущего программиста проекта Good & Evil (увы, закрытого вместе с Cavedog в начале 2000 года. События в игровом мире происходят с невероятной быстротой. И не всегда приятные. - Примеч. ред.).Ниже Курт предлагает несколько полезных рекомендаций для тех, кто хочет заняться написанием программ для современных игр.


Содержание раздела