• Игролог
• Игры
• Об авторе

Разработка игровой карты

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

Достоинства статических карт:

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

Недостатки статических карт:

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

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

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

Достоинства динамических карт:

• Маленький размер, поскольку экземпляр каждого объекта один, а при разработки уровня он копируется столько раз сколько нужно;
• Разные игровые объекты в разных комбинациях могут не только разнообразить внешний вид уровней но и менять игровой процесс;
• Легкость в разработке, уровни можно строить уже когда игра готова и не переживать за то что они окажутся тяжелыми для прохождения, ведь их можно в очень короткие сроки переделать полностью;
• Редактор карт можно сделать общедоступным за счет чего фанаты игры могут делать и публиковать свои уровни продлевая игре жизнь;
• Легкость в добавлении новых игровых объектов.

Недостатки динамических карт:

• Сложность создания хорошей детализации карты;
• Необходимость редактора уровней.

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

Примеры игр со статическими игровыми картами:

1. Machinarium
2. Scarygirl

— обратите внимание каждая игровая локация уникальна.

Примеры игр с динамическими игровыми картами:

1. Twin Shot 2
2. Rustyard

— все игровые уровни построены из повторяющихся блоков.

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

Этап первый

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

Масштаб для объектов как правило определяется исходя из общего игрового пространства (игрового экрана) и зависит от того в каком жанре игра и будет ли карта выходить за пределы экрана с возможностью прокрутки или перехода от экрана к экрану. Практически любая динамическая карта строится на основе сетки — это тоже самое что и тетрадка в клеточку. Сетка упрощает построение мира и его жизнь в будущем.

В моей игре игровой экран запланирован в 640x480 пикселей. Чтобы определить масштаб для такого пространства я просто создал холст с такими размерами и расчертил его в клеточку, размеры моей клетки составляют 64x64 пикселя. После чего стал рисовать схематичные наброски героев и объектов подбирая оптимальный размер сетки, так чтобы герой не казался слишком маленький и во круг героя был достаточный обзор во все стороны. Чтобы мир было проще создавать, желательно делать так чтобы каждый объект мог занимать только одну клеточку. Но существует необходимость когда должны быть объекты менее одной клетки (маленькие кустики, камни, указатели) или более одной клетки (дома, деревья) — подробнее о том как быть с такими объектами станет ясно далее по тексту.

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

Когда методом набросков мы определяем каким размером должны быть игровые объекты чтобы игроку было комфортно играть, мы подгоняем сетку под размер объектов если она сильно не соответствует размерам объектов. В моем случае размер клетки не изменился.

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

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

Важно! При построении игровой сетки существует одно очень важное правило, ширина и высота клетки должны делится на 2 без остатка. То есть такие размеры как например 21, 33, 65 и т.п. не подходят — этот нюанс может оказаться критичным при программировании.

Этап второй

С масштабами вроде определились, но прежде чем приступать к рисованию следует разделить все объекты на два типа:

• основные - с которыми может взаимодействовать игрок, монстры и другие объекты;
• оформление - объекты которые нужны просто для украшения.

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

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

Этап третий

Рисование графики следует начинать с рисования основы — это как правило грунт на котором растет трава, торчат камни, стоят дома и бегают герои. Грунт в играх представляется в виде набора тайлов (Tile — от. англ «черепица»). Тайл — это как керамическая плитка с разными узорами и цветами, из которой потом собирается цельный красивый орнамент.

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

Чтобы продемонстрировать использование тайловых наборов и сами наборы, я нашел в �?нтернет хороший пример:

Так выглядит готовая игровая локация собранная из отдельных кусочков.

А на этих картинках мы можем видеть отдельные тайлы из которых собирается игровой уровень.

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

В свое время я придумал как упростить работу над тайлами уменьшив их количество до минимума. �?дея заключается в расстановке тайлов в шахматном порядке. То есть имея буквально два вида тайлов и расставляя их в шахматном порядке можно получить довольно оригинальную текстуру. Правда такой вариант подойдет, пожалуй только для карт с видом сбоку.

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

В итоге у меня всего два тайла и такой результат в финале:

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

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

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

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

Этап четвертый

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

Объекты с которыми должен взаимодействовать персонаж желательно делать в пределах одной клетки. Но иногда возникает необходимость в объектах которые будут явно больше одной клетки — в таких случаях следует решить действительно ли нужны такие большие объекты? Если они действительно нужны и без них никак не обойтись, то первым делом следует подумать о том, можно ли их разбить на несколько составляющих объектов. Рассмотрим на примере моста: у моста есть поручни, столбики удерживающие поручни и полотно по которому бегает герой, если его грамотно разбить на составляющие детали то мы получим конструктор из которого можно собрать красивый мост любой длины.

В моем примере мост немного не доработан, в идеале в центр моста нужно добавить столбик, на который будут крепится веревки. �?ли если столбик рисовать лень, то просто изобразить веревки натянутыми чтобы они незаметно стыковались.

Еще бывают такие большие объекты, с которыми игрок может частично взаимодействовать — например дом. У дома для игры важна только дверь в которую игрок может входить, а с самим домом он никак не взаимодействует, в таком случае сам дом следует сделать как объект декорацию без двери, а дверь сделать отдельным объектом например с анимацией открывания и закрывания двери. Таким образом все объекты могут делится на части упрощая жизнь не только программисту но и художнику ;)

Далее по теме: Пишем редактор уровней. Вступление →