Как сделать игру в пейнте
Использование Paint в качестве редактора уровней
Всю сознательную программистскую деятельность я увлекался созданием игр и не любил делать редакторы и прочие утилиты. Главным моим редактором почти всегда был Paint. Но для игр, в которых уровень статичен и состоит из тайлов (Марио подобные и прочие танчики), это более-менее оправдано, т.к. одному пикселю из файла уровня, созданного в Paint, соответствует тайл в игре. А что если требуется создать игру, где нет тайлов, а игровая локация состоит из неровных скалистых пещер. Или игру, в которой много движущихся элементов (летающие платформы, лифты, циркулярные пилы, вращающиеся по окружности). 
Создавать редактор для таких целей мне по-прежнему не хотелось. О том, как я это решил с помощью Paint опишу в этой статье.
Я не буду приводить названия игр и давать ссылки на них, потому что это не демонстрация и не реклама игр, а описание метода, который в них применяется.
Неровная карта
Первая игра не блещет разнообразием геймплея: играем за некий подводный кораблик, двигающийся с помощью реактивного двигателя, и уворачиваемся от скал и прочих врагов:
Извиняюсь за качество видео, снимали на телефон
По видео видно, что локация состоит из земли (которой касаться нельзя), бекграунда, воды, крутящихся ежиков (враги) и эмиттеров, выпускающих эти ежики. Да, еще там есть рыбки и водоросли, но они генерируются случайным образом и не имеют отношения к файлу уровня.
Уровень из видео показан слева (увеличено в 4 раза):
В левом верхнем углу можно заметить зеленый пиксель, так отмечается стартовая позиция, следует запомнить это место, т.к. все последующие иллюстрации будут демонстрировать именно его.
Если это сейчас просто так взять и отрендерить (потайлово), то локация будет состоять из гигантских квадратов. Да и количество таких тайлов достаточно велико (61х69 для этой карты). Поэтому был применён другой способ рендеринга (нетайловый), при котором можно отобразить карту за один вызов (на самом деле за три: отдельно воду, бекграунд и финальная склейка). Это благодаря тому, что весь уровень помещается в одну единственную текстуру, назовём её tex_level. И натягивается она на полноэкранный квад (полигон, размером с экран). Перед этим выставляются текстурные координаты в зависимости от виртуальной камеры, которая привязана к персонажу. 
Слева – примерно так выглядит текстура tex_level и охват виртуальной камеры. Справа – назначенные текстурные координаты для полноэкранного квада, т. о. на экран попадает кусочек текстуры tex_level.
Вначале текстуру tex_level надо подготовить. Для этого заведём массив под пиксели этой текстуры:
где w – ширина файла с уровнем, h – высота, деленная на 3 (т.к. три слоя).
Теперь в цикле считываем каждый пиксель исходной карты из каждого слоя и в зависимости от цвета (он же и тип тайла) заполняем соответствующие цветовые каналы в пикселе pix, а именно:
Техническая особенность: на самом деле w и h равны ближайшей в сторону увеличения степени двойки для ширины и высоты карты, недостающие пиксели замащиваются красным цветом (земля), а этот цикл можно считать псевдокодом.
Видно, что один и тот же пиксель в массиве может содержать землю, воду и бекграунд. На основе массива pix создается текстура tex_level, сам массив pix нам ещё пригодится. 
Слева готовая текстура tex_level, а справа она же, но в игре. Камера в стартовой позиции.
Чтобы было удобнее продвигаться дальше, будем выводить только R канал из tex_level, т.е. только землю.
Для начала нужно избавиться от этих гигантских квадратов. Для этого массив pix перед тем, как его передать в текстуру tex_level следует размыть по Гауссу (радиус размытия подбирался опытным путем). Теперь всё та же локация выглядит уже куда лучше: 
Слева земля до размытия, справа после.
Техническая деталь: перед размытием надо растянуть в 2 раза массив pix так, чтобы исходный пиксель занимал бы уже 2х2 пикселя в растянутом массиве.
Но граница земли здесь очень размыта. Для понимания процесса превращения размытой границы в четкую (назовём этот процесс фильтр четкой границы) рассмотрим одномерный случай, т.к. он аналогичный. Тогда размытая граница земли будет выглядеть примерно так:
Вычтем из этого графика 0.5, домножим на какое-нибудь большое число (в данном проекте это 50) и обрежем (операция clamp) по границе [0; 1], т.е. всё, что меньше 0 превращается в 0, а всё, что больше 1 превращается в 1: 
В итоге белый цвет не мгновенно переходит в черный (это важно).
Теперь проделаем все эти операции с нашей текстурой tex_level. Пусть в level_color хранится выборка из этой текстуры, тогда фильтр выглядит так: clamp((level_color.r – 0.5) * 50.0, 0.0, 1.0)
В левой части tex_level + noise, в правой части фильтр четкой границы.
Техническая деталь: диапазон значений в текстуре noise от 0 до 1, поэтому к выборке из tex_level следует прибавлять (noise — 0.5) * k, где k – коэффициент возмущения границы (в проекте он равен 0.3).
Теперь осталось просто наложить текстуры. Текстура земли уже есть (это просто обычная текстура), а вот воды еще нет, нужно её сперва подготовить.
Алгоритм абсолютно такой же, как и с землей, только вместо выборки из R канала следует делать выборку из B канала, т.к. именно там и содержится вода. Еще одно отличие – это вместо обычного шума применяется анимированный шум (плавно меняющийся во времени) для создания волн на границе воды и воздуха. Создание анимированного шума выходит за рамки данной статьи. В этом этапе применяем текстуру неба, а роль воды выполняет синий цвет (подбирался опытным путем). Все шаги этапа получения слоя с водой проиллюстрированы ниже:
Слева направо: размытая граница воды, анимированный шум плюс фильтр, интерполяция из синего цвета в текстуру неба.
Следующий этап – это рендеринг бекгруанда. На этот раз выборку из tex_level производим из G канала. В этом этапе ничего принципиально нового нет: получаем маску бекграунда и интерполируем текстуру камней (это в данном случае) и текстуру воды из предыдущего этапа. Конечно, есть свои тонкости: на подводную часть бекграунда накладываются дополнительные фильтры, то же самое и для самой воды для придания эффекта толщи воды, но это выходит за рамки статьи. В этом же этапе рендерятся декоративные элементы: рыбки и водоросли. Окончательно слой с бекграундом выглядит так:
Технические подробности: для придания эффекта «шевелящихся водорослей» из-за подводных течений использовалось смещение x-компоненты текстурных координат при рендеринге спрайта с водорослями. Величина этого смещения считывалась всё из той же текстуры с анимированным шумом.
И последний этап – склейка. Получив в начале статьи маску земли, применяем её для интерполяции текстуры земли и слоя с бекграундом. Финальный результат выглядит так:
Развитие идеи. Что если требуется накладывать несколько текстур на землю, тогда просто добавляем ещё один слой, в котором пиксели земли раскрашиваем в 4 разных цвета (можно меньше, но не больше). Из этого слоя создается отдельная текстура-маска (4 цвета в слое – 4 цветовых канала в маске), но тогда придется делать дополнительные пять текстурных выборок вместо одной (одна из маски и 4 из соответствующих текстур земли).
Определение коллизий
Это отличается от картинки с размытой границей, потому что там применялась билинейная фильтрация, а тут лишь сырые значения массива после размытия.
Значения из этого массива напоминают карту высот, можно подобрать такое значение высоты, которое примерно совпадает с визуальной границей земли (подбираем опытным путем). Для более точного определения высоты необходимо использовать билинейную интерполяцию. А если вычислить три высоты в окрестностях некой точки, то можно довольно точно определить градиент в этой точке, а он совпадает с нормалью к визуальной поверхности земли. Нормаль в этой игре использовалась лишь в одном месте – для огибания реактивной струёй поверхности земли:
Динамичная карта
Итак, первая проблема, поставленная в начале статьи, решена: никаких тайлов не видно, одни неровные скалистые пейзажи. А как быть с движущимися элементами? Это покажет вторая игра – аналог super meat boy:
Здесь много подвижных элементов: циркулярные пилы, двигающиеся по прямой или вращающиеся вокруг центра, перемещающаяся платформа с шипом и пилой, двери, рассыпающиеся тайлы. А пилы ещё имеют разный размер.
Процесс рендеринга полностью аналогичен первой игре, поэтому ограничимся рассмотрением формата карты. Карта из видео выглядит так (увеличено в 5 раз): 
Данная карта состоит из шести (!) слоёв (всего в игре есть пять разных типов слоёв, все они здесь представлены). В отличие от предыдущей игры количество слоёв здесь может быть любым. В левом верхнем углу есть набор пикселей (их ровно столько, сколько и слоёв). Они-то как раз и задают тип слоя (это позволяет не заботиться о порядке и количестве слоёв). Первые два слоя очевидны: слой объектов – взаимодействующие элементы с игроком (земля, шипы, пилы, старт, выход, рассыпающиеся тайлы) и слой бекграунда. Четвёртый слой тоже, как и первый, является слоем объектов (4-й пиксель в левом верхнем углу тоже черный). Пришлось вынести некоторые объекты в этот слой, потому что они пересекались с другими объектами (теоретически одинаковых слоёв может быть сколько угодно).
Техническая особенность: в текстуру tex_level помещается только замля и бекграунд (воды в этой игре нет), а все остальные объекты считываются из файла уровня в массив.
В пятом слое указываются размеры пил в градациях красного. Если для пилы отсутствует красный пиксель из этого слоя, то размер её берется по умолчанию. А в шестом слое находятся траектории и скорости для перемещающихся групп в градациях серого, ну и скорости и направления для вращающихся пил. В некоторых слоях есть посторонние цвета, которые в данном слое не участвуют, при загрузке карты они просто игнорируются (например, почти во всех слоях есть черные пиксели земли, они были нужны лишь при составлении карты, для навигации относительно них).
Развитие идеи. Теоретически с помощью Paint можно создать карту для 3D-шутера, файл карты будет состоять из матрицы слоёв. Строка этой матрицы соответствует высоте слоя в игре, а в столбцах содержатся слои одного типа. Например, в 1-м столбце будет геометрия карты (один слой – это срез карты на данной высоте), во 2-м столбце можно назначать текстуры с помощью ключевых цветов пеинта, в 3-м расставлять объекты и т.д.
Вот, пожалуй, и всё. Надеюсь, тема «редактор карт из Paint» раскрыта.
Читают сейчас
Редакторский дайджест
Присылаем лучшие статьи раз в месяц
Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.
Похожие публикации
West Game Development Forum: Create, Share, Improve
Android NDK Game Development Cookbook
HTML5 Audio и Game Development: баги браузеров, проблемы и их решения, идеи
Средняя зарплата в IT
AdBlock похитил этот баннер, но баннеры не зубы — отрастут
Минуточку внимания
Комментарии 27
Самое забавное во всем этом, что редактор, который бы позволил делать также карты можно написать самому за один вечер. Только для каждого квадратика хранить не несколько байт с цветом, а данные у вдобном для программы виде и любом количестве.
Подобный подход сам использовал. И не однократно, но он подходит разве что для прототипирования. Для левел-дизайнера это котироватьяс не будет вообще никак, так как тут даже украшательства нельзя воткнуть самому. А усложнение уровня путем создания нескольких картинок, вообще сделает для дизайнера это адским испытанием.
Но за статью всёравно спасибо, почитать интересно.
Так, мне эти разговоры про рендер заранее надоели.
Возьмем самый маленький уровень (он же 1-й)
Его размер 47х33 тайла
На экран попадает ровно 15 тайлов по горизонтали (на айпаде), рендеринг произвожу в текстуру 1024х768
Т.е. один тайл занимает примерно 1024/15=68.3 пиксела (примерно 70) в ширину, а он еще и квадратный, т.е. 70х70
Т.о. чтобы сохранить пиксельность уровня нужно заготовить заранее под него текстуру 3290х2310
Теперь возьмем самый большой уровень 91х196. Для него уже потребуется текстура 6370х13720, тогда как на моем айпаде 4 максимальный размер текстур 4096х4096. Как вариант, можно разбить эту текстуру на много маленьких (1024х1024 например) так, чтобы все они покрывали уровень. Один фиг, большой уровень потребует 6370х13720х4=350М
Даже если все это таки сделать, шейдер уровня будет нетривиальный (не, не просто так взять выборку из текстуры и поместить на экран). Нужно произвести смешивание со скайбоксом, На участке, где вода (а её кстати где хранить в большой текстуре, она ведь пересекается с бекграундом, альфаканал уже занят под маску скайбокса) произвести искажений бэка и водорослей и «замутнить» бэк (типа толща воды). А как сделать выплывание рыбок из-за земли, но поверх бэка? (бэк и земля ведь не отдельно хранятся, а в большой текстуре) Обрезать? Как? Хранить землю и бэк таки в разный текстурах? Ладно, тогда 700М.
Оно того стоит? Тогда как я с помощью шейдера рендерю нужный мне кусок уровня с 60фпс
update: только что вспомнил, разрешение маски уровня апается в два раза, поэтому умножаем память еще в 4 раза
Это все напомнило мне детство.
Помн лет в одинадцать (примерно 1991 год) написал какую-то простенькую леталку-стрелялку на компилируемом бейсике на писюке.
Но Писюки тогда были не очень доступны. Я ходил в какой-то институт где работали знакомые, игрался за машинкой с зелено-черным монитором (черно-белые были только у крутых). Никаких жестких дисков — только дискеты. Комп с жестким диском на 20мегабайт был только один и к нему меня не пускали.
В общем доступ был ограничен, экран одноцветный… А дома стоит Спектрум. Цветной.
Портировал код один в один благо диалекты бейсков не сильно различались.
Но восьмибитный проц да интерпретируемый бейсик сделали задачу неосуществимой. Мои полностью рандомные горы на писюках требовали солидной задержки, а тут двигались столь медленно, что играть было нереально.
Альтернатива портирования всей игры на ассемблер меня не привлекала, хоть я ассемблер и знал и писал на нем небольшие куски для усиления. Вариант выноса только блока рисования гор тоже не помог — я вызывал системную процедуру рисования линий, и это все равно было медленно.
Тогда я решил «испортить» качество гор заменив их на четыре вида спрайтов — полностью твердый, полностью воздух и два варианта наклона — влево и вправо. Вывод таких «символов» с перегруженным шрифтом оказался заметно быстрее, плюс ширина блока сократилась в восемь раз (ширина символа).
В результате такой оптимизации (первой в моей жизни) я смог остаться в рамках бейсика и получить приемлимую производительность (даже задержку ввел небольшую).
Вот забавно — сейчас можно рендерить по живому не заморачиваясь о производительности, а тогда приходилось выкручиваться и рендерить по живому потому что места для заранее сгенеренных текстур тупо не было. Магнитофоны были слишком медленными, а дисководы были не у всех…
Это только так кажется что страшно.
А на самом деле тогда просто время такое было.
Впервые я увидел компьютер в девять лет, когда пришел в лабораторию к деду. Дед был доцент на кафедре ВОЛС и они там вечно что-то изобретали, испытывали, рассчитывали… Машинка называлась СМ1800. Характеристики ее я не помню, но там были два пятидюймовых дисковода с маленькой ёмкостью (что-то вроде 90кб) и монитор… монитор был текстовый. Т.е. от системного блока размером с приличную тумбочку шел не аналоговый сигнал а текстовый, и в мониторе уже был свой контроллер который всё это превращал в аналоговый сигнал для трубки.
За компом сидел сын дедушкиного коллеги. Пацан был на три года меня старше и с умным видом писал что-то на бейсике.
Писал он как оказалось примитивнейшую игрушку — в консоли запрашивается твое имя, тебе говорят «Привет *юзернейм*!», тебя спрашивают мол хочешь ли ты поиграть, если да, то компьютер загадывает число (взятое из констант ибо ГСЧ или не было или пацан о нем не знал), ну и так далее… В общем обычная лапша из print input if goto
Поскольку логика «игры» была очевидна, тем более что парниша периодически тестировал, то значение этих трех-пяти команд понять было не сложно. Строки нумерованы… В общем когда парниша вышел в туалет я не удержался и сел за комп. Написал буквально три строчки с еще одним вопросом. Когда парень пришел проворчал с минутку мол он мне не разрешал, но код одобрил и пошел писать дальше… Вот реально ведь ничего сложного — как обезьяна повторил чужие действия.
Ну а дальше имея уже какой-то опыт прочитать книжку и разобраться в синтаксисе было не сложно.
Использование ассемблера в то время тоже было неизбежным, поскольку на спектруме фактически было только два языка — системный встроеннный бейсик и ассемблер. Да были еще паскали да фортраны, но в реальности на таких малых мощностях машины (48кб ОЗУ из которых часть забирает видеопамять и система, 16кб ПЗУ, восьмибитный проц на пару мегагерц, магнитофон вместо дисковода) использовать их было не особенно реально — компилятор/интерпретатор, исходник, бинарник… при этом бейсик никто не отменял он ведь часть ОС… В общем вариантов особо не было. Поэтому графика писалась на асме.
Ну как писалась — брались примеры из книжек и допиливались до своих нужд… Да на писюках был паскаль (я как-то с паскаля начинал). Но там опять таки с библиотеками было довольно туго. Интернета тогда еще не было, поэтому если в моем окружении библиотек не было значит их для меня не было. Зато были книги. И в книгах было прекрасно написано через какие прерывания и каким образом можно получить те фичи которых не было в стандартных библиотеках. Например хотелось использовать SVGA-режимы которые уже были в моем компьютере (чуть позже чем в 91-ом) но в стандартных библиотеках доступен был только VGA. Пришлось писать в паскале небольшие включения ассемблера…
Но на самом деле в ассемблере нет ничего такого страшного.
Это только кажется что сложно.
А когда ты уже умеешь писать лапшу на бейсике то изучить ассемблер не сложно.
По сути там что? Пару команд условных/безусловных переходов, копирование в регистр/из регистра сложения/вычитания всякие…
Для человека который привык к лапше классического бейсика (с нумерациями строк) в принципе ничего сложного — просто лишаешься небольшого количества синтаксического сахара и вынужден часть механической работы делать сам (планировать память, исправлять адреса переходов изменяя место в памяти, отлаживать в уме или на листочке полученный код и т.п.), но тут много думать не нужно — просто внимательным быть и всё. Ну и если хочешь чтоб код был достаточно шустрым то нужно грамотно планировать память, особенно регистры. Но опять таки — ну нет тут ничего сложного, да и в небольшом куске кода можно и поговнокодить даже по тем меркам.
Вот что по настоящему было сложно так это всё это забыть.
Да, да, забыть!
Я помню свои эмоции когда я впервые столкнулся с языком без goto. Я думал что с меня издеваются, и не понимал как вообще можно жить без прямых переходов. И это я к тому времени уже писал на процедурном диалекте бейсика.
Так же самом помню как я сильно возмущался спустя много лет после этого когда в пхп вернули GOTO. Я то помню как это все выглядит, и как сложно было эту лапшу выбить из меня…
Так что как по мне так Си в 13 лет знать это круче чем ассемблер в 11. И главное полезнее 🙂