Как сделать платформер

Обновлено: 05.07.2024

Итак, ищем на этом сайте эту программу, и качаем. Желательно купить лицензию за 20 $, что бы иметь больше возможностей. Без лицензии вы не сможете создать полноценную игру (хотя это можно, но проще будет с лицензией). Ознакомьтесь с примерами, которые даны вместе с программой, прочитайте основы программы в файле помощи. Вы наверно спросите, зачем нам эта статья, если всё подробно расписано в официальном файле помощи к игре? Да затем, что в официальном файле помощи описаны только коды и основы их пользования, а я расскажу, как сделать игру определенного жанра.

Вы ознакомились с Game Maker, теперь обязательно выучите хотя бы основы GML. Хотя ниже описанный пример platf_primer.gm6 будет использован преимущественно на кнопках (триггерах).

Для лучшего понимания про создание платформера, вместе со статьёй, есть пример платформера platf_primer.gm6 .

Начнём с создания персонажа. Создаём объект, называем например obj_player. Задаём ему движения в разные стороны. В кнопке Left проверяем столкновение объекта, как это показано в примере, и собственно смещение персонажа по оси x на координаты -4. Так само и Right, только координаты +4. И не забываем об изменении спрайтов. Красным шрифтом на рисунках отмечены мои текстовые объяснения действий.

ПРИМЕЧАНИЕ: ЕСЛИ НА РИСУНКАХ ДЛЯ КООРДИНАТ УКАЗАНЫ ЗНАКИ + ИЛИ – , ЭТО ЗНАЧИТ ЧТО ПРИ СОЗДАНИИ ДЕЙСТВИЯ НУЖНО ПОСТАВИТЬ ГАЛОЧКУ НА RELATIVE.

Теперь персонаж ходит влево и вправо. Пожалуй, самое важное в этих играх это гравитация, и естественно нужны платформы. Создаём ещё один объект, назовём его obj_platform – это будут наши будущие платформы описанные выше. Обязательно ставим галочку Solid (твёрдый) в obj_platform.

Переходим опять к obj_player. В Step ставим условия, показываемые на скриншоте и в примере:

Здесь так же объясняются все кнопки, для чего они, и что они дают. Я просто хочу, что бы не бездумно взяли мой пример платформера, и просто вставили свои спрайты. Я хочу, что бы вы поняли, как это всё работает.
Переменная, отображённая ниже, поможет вам ограничить скорость падения до 12 максимум. Это поможет вам избавиться от бесконечного увеличения скорости падения.

Теперь важно сделать прыжок персонажа. Давайте замахнёмся сразу на двойной прыжок.


Теперь при создании персонажа переменная будет равняться нулю.
В Событии press (нажать кнопку вверх) создаём такое:

И теперь создаём цепочку действий в касании с объектом obj_platform.

В принципе, основной движок для нашего платформера готов! Но давайте внедрим в него дополнительные функции.

Давайте сделаем лестницы. Лестницы мы сделаем в событиях Step, Up, Down. Создаём новый объект, и назовём его obj_ladder.

В Step создаём следующие действия:

В Up, создаём следующее…

В Down создаём тоже самое, что и в Up, но координату y=-4, надо заменить на y=+4
Лестница готова.

Создаём объект врага. Назовём obj_enemy. Врагам в событии Create создаём действие, указанное на рисунке, и ставим в нём всё как указанно на скриншоте.

Ещё нам понадобится объект obj_rotate и сделать его невидимым (убрать галочку Visible).

Во враге создаём событие столкновения с obj_rotate и вставляем следующее действие:

При касании к этому объекту, враг будет менять своё направление, и идти в обратную сторону. То есть так мы устанавливаем области патрулирования врагов.

И в событии столкновения с obj_enemy:

Теперь при касании к врагу, у вас будет отниматься одна жизнь.

Так же само, как и врага, делаем штыки, только они не двигаются. При касании к ним ставим
– то есть -1 здоровья. И при касании к штыкам, будет уменьшаться здоровье.

Когда здоровья будет меньше одного, отнимается одна жизнь.

Вот уже можно сделать неплохой платформер. Идём в комнату и делаем уровень. Расставляем блоки, персонажа, врагов и прочее…

Давайте сделаем, что бы наш платформер был не просто на одной картинке, а был большой уровень, и камера следила за персонажем. Для этого в комнате во вкладке views (виды) делаем следующее:

Hbor и Vbor нужно менять. Это координаты x и y при достижении которых, камера будет двигаться. Например, для вида размером 640х480 можно поставить Hbor:320; Vbor:240. Тога камера будет следить чётко по центру за персонажем.

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



Кадр из игры Mega Man X. Видны границы ячеек и hitbox (зона поражения) игрока.
Примеры игр: Super Mario World, Sonic the Hedgehog, Mega Man, Super Metroid, Contra, Metal Slug, и практически все остальные платформеры 16-битной эпохи.

Как это работает.

Если предположить, что на карте нет наклонных и односторонних платформ, алгоритм несложен :

1. Последовательно разбить на шаги движение по осям X и Y. Если затем вы планируете ввести наклоны, начните разбивку с оси Х, в противном случае порядок не имеет большого значения. Затем, для каждой оси:

2. Найдите координату края, направленного вперёд (ведущего края). Например, при движении влево это координата Х левой стороны ограничивающего прямоугольника, при движении вправо – коорднината Х правой стороны, при движении вверх – координата Y верхней стороны и т. д.

3. Определите, с какими линиями сетки пересекается ограничивающий прямоугольник – так вы получите минимальное и максимальное значение на противоположной оси (т.е. при движении по горизонтали мы найдем номера вертикальных ячеек с которыми пересекаемся). К примеру, если вы двигаетесь налево, игрок пересекает ряды номер 32, 33 и 34 (то есть ячейки с координатами Y = 32 * TS, Y = 33 * TS, и Y = 34 * TS, где TS = размер ячейки).

4. Проследуйте дальше по линии ячеек в направлении движения пока не найдёте ближайшее твердое препятствие. Затем пройдитесь по всем движущимся объектам, и определите ближайшее препятствие среди них на вашем пути.

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

6. Передвиньте игрока на новую позицию. С новой позиции, повторите шаги, и так далее.

Наклоны


Наклоны (ячейки, на которые указывают зелёные стрелки) могут представлять определённую сложность, так как они по сути являются препятствиями, но при этом игрок всё же может частично входить в эти ячейки. Они также предполагают изменение Y координаты персонажа в зависимости от движения по оси X. Во избежание проблем, нужно сделать так, чтобы ячейка содержала параметр “floor y” каждой стороны. Если в системе координат обозначить левую верхнюю ячейку как , как показано на рисунке, тогда точка – это ячейка, расположенная чуть левее от персонажа (первая ячейка наклона); ячейка, на которой он стоит – точка , затем , и . Далее ячейки начинают повторяться, с новой точки и далее, а дальше спуск становится круче и состоит из двух точек и .


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

Для вертикального движения:

Односторонние платформы


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

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

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

Лестницы (вертикальные)


Лестницы могут показаться сложными для реализации, но они попросту представляют собой другое состояние персонажа: будучи на лестнице, игроком игнорируется практически вся система столкновений, и вместо неё вводится новый набор правил. Обычно, ширина лестницы – одна ячейка.

Таким образом, возникает эффект моментального совмещения x-координаты игрока с лестницей. Для движения вниз с верхушки лестницы нужно переместить y-координату персонажа так, чтобы игрок оказался внутри лестницы. В некоторых играх для таких ситуаций вводится альтернативный хитбокс, отслеживающий позицию игрока в пределах лестницы. К примеру, в Mega Man, он представляет собой единичную ячейку, совпадающую с верхней ячейкой спрайта персонажа.

Покинуть лестницу можно следующими способами:

■ Игрок достигает верха лестницы. Здесь обычно включается особая анимация, при которой игрок перемещается на несколько пикселей вверх по оси Y и оказывается над лестницей в стоячем положении;

■ Игрок достигает низа висячей лестницы. В этом случае игрок попросту падает, хотя в некоторых играх это не допускается;

■ Игрок движется влево или вправо. Если нет препятствий, игрок сходит с лестницы в соответствующем направлении;

■ Игрок прыгает. В некоторых играх позволяется отпустить лестницу таким образом.

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

Лестницы (наклонные)


Данный тип лестниц встречается редко. В основном, наклонные лестницы присущи играм серии Castlevania. Их реализация во многом совпадает с реализацией обычных лестниц, за некоторыми исключениями:

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

Движущиеся платформы


Для решения этой проблемы существует несколько путей. Рассмотрим такой алгоритм:

■ Перед тем как что либо сдвинуть на карте, задайте условие, при котором игрок считается находящимся на движущейся платформе. Пускай программа следит за тем, чтобы, например, нижний средний пиксель персонажа располагался ровно на один пиксель выше поверхности платформы. Если это условие соблюдается, сохраните указатель на платформу и её позицию в персонаж
■ Сдвиньте все движущиеся платформы на один шаг. Обязательно сделайте это перед тем, как будете двигать персонажей и другие объекты;
■ Для всех персонажей, стоящих на движущейся платформе, определите дельта-положение платформы, т. е. полное перемещение, совершённое ей по каждой оси. Затем, переместите персонажа в соответствии с этим значением;
■Передвигайте персонажей дальше как обычно.

Другие особенности


Есть игры, в которых применены гораздо более сложные и уникальные техники, и особенно в этом плане выделяется серия Sonic the Hedgehog. Эти приёмы выходят за рамки данной статьи, но могут послужить материалом для будущих.


Примеры: Worms, Talbot’s Odyssey

Как это работает

Склоны


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

Приведу в общих чертах алгоритм, изпользуемый в Talbot’s Odyssey:

■ Найдите растояние, на сколько нужно сместиться по каждой оси;
■ Шаги нужно проводить по каждой оси отдельно, начиная с той, на которой наибольшее смещение;
■ Для движения по горизонтали, ограничивающий прямоугольник игрока (AABB) нужно сместить на 3 пикселя вверх(чтобы он смог забираться на склоны);
■ Выполните проверку столкновений, сверяясь со всеми препятствиями и самой битовой маской, и определите, на сколько пикселей персонаж может продвинутся, прежде чем столкнуться с чем-либо. Передвиньте его на эту новую позицию;
■ Если движение шло по горизонтали, передвиньтесь вверх на столько пикселей сколько необходимо (обычно, не больше 3-х) чтобы компенсировать склон;
■ Если в конце движения хотя бы один пиксель игрока накладывается на препятствие, отмените движение по этой оси;
■ Независимо от исполнения предыдущего условия, примените алгоритм для второй оси.

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

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



Braid (редактор уровней) с видимыми слоями (наверху) и …полигонами (внизу)

Как это работает
Есть два основных способа этого достигнуть:
1. Движение и столкновения реализуйте способом похожим на битовую маску, но используя при этом многоугольники, чтобы вычислять отклонения и получать правильный наклон.
2. Используйте физический движок (например, Box2D)
Очевидно, второй способ более распространенный (хотя я подозреваю, что Braid первый), потому что он проще и позволяет делать различные вещи с динамикой в игре.
К сожалению, приходится быть очень внимательным, когда идешь этим путем, чтобы не превратить игру в обычный физический платформер.

Составные объекты

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

Существуют различные способы решения этой проблемы, но наиболее популярным решением является разделение персонажа на несколько разных многоугольников: так, помимо туловища, у вас будет узкий прямоугольник для ступней и два узких прямоугольника для боков, еще один для головы или другая подобная комбинация. Иногда им придают коническую форму, чтобы избежать препятствий. У них разные физические свойства, и функции определения пересечений движка в данном случае используются для определения состояния персонажа. Для получения дополнительной информации могут быть использованы датчики (несталкивающиеся предметы, используемые только для проверки наличия перекрытий). К ним можно прибегнуть, чтобы определить достаточно ли близко к полу мы находимся для прыжка или персонаж упирается в стену и т.д.

Ускорение


Super Mario World (низкое ускорение), Super Metroid (среднее ускорение), Mega Men 7 (высокое ускорение)

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

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

Как это работает

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

Два вида ускорения:
Среднее взвешенное : число (“a”) от 0 (без движения) до 1 (мгновенное ускорение).
Используйте это значение для вставки между заданной и текущей скоростью, а результат установите как заданную скорость.

vector2f curSpeed = a * targetSpeed + (1-a) * curSpeed;
if (fabs(curSpeed.x)

Добавочное ускорение: Мы определим, в каком направлении добавить ускорение (используя функцию sign, которая возвращает 1 если аргумент больше нуля и -1 если меньше), затем проверим, не вышли ли мы за рамки.

vector2f direction = vector2f(sign(targetSpeed.x – curSpeed.x), sign(targetSpeed.y – curSpeed.y));
curSpeed += acceleration * direction;
if (sign(targetSpeed.x – curSpeed.x) != direction.x)
curSpeed.x = targetSpeed.x;
if (sign(targetSpeed.y – curSpeed.y) != direction.y)
curSpeed.y = targetSpeed.y;

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

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

Контроль прыжков

Существуют четыре основных способа управления прыжками:

Анимация и управление


Black Thorne, анимация персонажа замедляется перед выстрелом назад (кнопка Y)

Во многих играх анимация вашего персонажа будет проигрываться до реального выполнения требуемого действия, во всяком случае, в играх, основанных на резких движениях. Это разочарует игроков, поэтому НЕ ДЕЛАЙТЕ ЭТОГО! Вам следует ставить на первое место анимацию, когда речь идет о прыжках и беге, но если вам не все равно, ограничьтесь такой анимацией, чтобы само действие происходило независимо от анимации.

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

· Используйте числа с плавающей запятой (тип float) для всех расчетов и хранения данных положения, и подводите итог в целых числах всякий раз, когда вы визуализируете изображение или рассчитываете коллизии. Быстро и просто, но при удалении от (0,0) начинает теряться точность. Это, вероятно, не имеет значения, если у вас очень большое игровое поле, но об этом следует помнить. В противном случае используется тип double.

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

Сегодня я хочу поделиться с вами некоторыми рекомендациями для создания платформеров от Scott Rogers — этот человек принимал участие в разработке: God of War, Maximo series, Pac-man World, Dawn to Life series, Darksiders и другие.

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

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

Автором оригинальных рекомендаций является Scott Rogers, а сами рекомендации были опубликованы еще в далеком 2008 году. Впрочем с тех пор данная информация совсем не потеряла актуальности. Я, как и автор данных рекомендаций, надеюсь, что они помогут сделать ваш платформер лучше и интереснее. Приступаем!

Кликайте на картинки чтобы их увеличить.

Title

Page 01

Page 02

Page 03

Page 04

Page 05

Page 06

Page 07

Page 08

Page 09

Page 10

Page 11

Page 12

Page 13

Page 14

Page 15

Page 16

Page 17

Page 18

Page 19

Page 20

Page 21

Page 23

Ссылки по теме

Ну и напоследок несколько ссылок по теме, включая архив картинок в оригинальном размере:

А при разработке Зомботронов все это было осмыслено и учтено?

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

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

Кстати, про магическую цифру 3, подтверждаю — идеальная цифра, тоже постоянно ей пользуюсь. Сколько надо сделать видов камней? Мм.. пусть будет 3, а сколько сделать видов деревьев? Тоже 3! А почему 3? Ну не много вроде и не мало, при этом и разнообразие какое-то получается — так я рассуждал несколько лет назад, а сейчас уже просто за правило взял, ведь во всех проектах это сработало на ура ;)

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

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

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

Читайте также: