Игровой шедевр своими руками

 | 13.04

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

Количество игр на сегодняшний день настолько велико, что свежие идеи генерировать становится всё сложнее. Как известно, один ум хорошо, а два лучше — так что создателей должно быть как минимум двое: программист и художник (2D или 3D, в зависимости от проекта). Итак, мы можем определить оптимальный состав команды для создания успешной и продаваемой игры для PC.

Небольшая 2D-игра (казуальная, в стиле Hidden Objects, к примеру): программист, 2D-художник (лучше 2-3 человека), музыкант (частичная занятость), гейм-дизайнер (он же балансировщик).

Достаточно трудоемкая 2D-игра (стратегия, RPG, action): программист (лучше 2-3 человека — главное, чтобы процесс работы был непрерывным, а результаты можно было легко и быстро совместить: например, один занимается игровой логикой, другой — спецэффектами, третий — локациями и т.п.), несколько художников (тут главное — качество их работы, а не их количество), гейм-дизайнер (он же балансировщик), музыкант и хотя бы один тестер (очень важно, чтобы игру «проверял» не тот, кто её делал, потому что последний сделает это не как будущий игрок… :-).

Таким же должен быть состав творческого коллектива для работы над трехмерными играми, только художники должны разбираться в 3D-составляющей, или же должен быть моделлер (один — если он профессионал, несколько — в ином случае), желательно также, чтобы художники имели специализацию, пусть это будут три человека: моделлер, текстуровщик, аниматор. Естественно, это довольно субъективное мнение, многое зависит от умений, навыков и опыта каждого человека.

Теперь рассмотрим «случаи из жизни» — так сказать, судьбоносные моменты в процессе разработки.

Совмещение программной, художественной и других составлЯющих в игре

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

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

Для ответа на эти вопросы вам нужно чётко разобраться с возможностями движка, который был избран, узнать его технические характеристики, найти все необходимые утилиты и дополнения, узнать возможность их использования (бесплатные или платные).

Кстати, очень важно при выборе игрового движка учесть, open-source он или нет. Если разработчик игрового движка не предполагает отдавать исходники, вы можете оказаться в такой ситуации, что созданную вами игру никто не захочет продюсировать и продавать из-за того, что в ней, скажем, нет возможности поставить в игру в режим паузы, когда из её Windows-окна теряется фокус. И вы в этом не виноваты, потому что пишете на скриптах, которые не предполагают такой функциональной возможности :-). Это только один пример, таких нюансов может быть много…

Хорошо, если есть возможность подключать динамические библиотеки dll в игру — таким образом можно исправить хотя бы эту конкретную проблему: написать С++ функцию, которая будет проверять состояние окна, а из скриптов по таймеру вызывать эту функцию и проверять, активно ли приложение.

Шрифты в игре

Зачастую используется один тип шрифта во всём проекте, разве что разных размеров. Но как использовать именно «этот» шрифт, необходимый? Обычно шрифты не берутся стандартные, их рисует художник, иногда — каждую букву, а потом специальной утилитой шрифт должен «собраться» для игры и в дальнейшем достаточно просто использоваться в ней скриптовыми функциями.

Моделирование

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

Но задумывались ли вы над тем, как именно надо моделировать, чтобы всё потом было отлично? Например, игровой движок Blitz3D не всегда хорошо воспринимает некоторые стили моделирования. То есть, надо учесть, что FPS в игре может резко сократиться при загрузке даже одной модели, если она, допустим, сделана таким образом, что полигоны пересекаются, или на ней многослойно и насыщенно размещена текстура, или же объект находится непосредственно перед игровой камерой.

Разные движки по-разному работают с моделями — иногда на значение FPS приятнее смотреть, когда большинство объектов вне видимости камеры, иногда это вообще не имеет значения. Кстати, обычно движки больше любят 10 моделей с общим количеством полигонов 1000, чем 100 моделей по 10 полигонов.

Изображения

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

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

Рис. 1. Так выглядит подготовленное изображение

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

Изображения больше 500х500 пикселей лучше оставлять в хорошем качестве, сколько бы оно не занимало, потому что это повлияет на восприятие игроком графических сцен. Если же картинки маленькие — им нужны альфа-каналы (черно-белые файлы, которые указывают, где изображение показывается, а где прозрачная область. Классический случай: белое — видимая часть, черное — нет. Также могут использоваться их оттенки для плавных переходов (рис. 1).

Таким образом мы получим 2 файла, общий размер которых будет меньше 300 Кб.

Текстурирование

Рис. 2. 2. Пример экономии — несколько текстур в одном файле

Это один из самых важных процессов, если разрабатывается трехмерная игра. Во-первых, очень важно, чтобы размер изображений-текстур находился в рамках 32х32, 64х64, 128х128, 512х512. На сегодняшний день мало видеокарт, которые не поддерживают текстуры, например, 384х143, — но они есть.

Помните, что картинка загружается полностью в память, и если реально там видно 40х40 пикселей, а рисунок 64х64, то в памяти сохраняется именно изображение размером 64х64 пикселя. При моделировании части текстур для модели (моделей) по возможности лучше компактно располагать их в одном файле-текстуре (как на рис. 2), а накладывать текстуру — специальными модификаторами (например, в 3ds max — UnWrap’ом).

Написание кода

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

Числовые значения лучше всего определять в начале функции или логического блока с помощью переменных (если вдруг значение нужно будет поменять, вам не понадобится искать по телу кода все места, где оно используется).

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

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

Эффекты в игре

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

Для создания разнообразных эффектов обычно используются встроенные в движок редакторы. Но вы также можете легко прибегнуть к помощи скриптов. Например, движок Torque2D организован таким образом, что с его помощью все картинки и другие gui-элементы можно хранить в так называемых контейнерах. Чтобы плавно отображать картинку (слева направо, к примеру), можно менять размер контейнера, не изменяя положения и размера дочерних элементов-картинок — таким образом получится эффект плавного появления изображения. С помощью значений прозрачности, изменения положения картинок, анимации можно создать много красивых эффектов.

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

Вячеслав КЛИМЕНКО, Игорь АРСЕНЮК

Robo User
Web-droid editor

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *