Головокружительное представление игрового уровня (формат)

Question

Как бы вы сохранили игровой уровень для Dizzy-подобной приключенческой игры? Как бы вы указали пешеходные зоны и графику? Является ли это основанным на плитке, основанным на пикселях или проходимым, поверхности могут быть описаны векторами?

Answer 1

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

Хотя современные машины работают быстрее, уровни прокрутки по длинной стороне делают такой подход непрактичным, ИМХО. Вы должны пойти с более разреженными представлениями.

Один из вариантов - «превратить» вашу игру в невидимые плитки, которые легче представить. Основная проблема заключается в том, что он может ограничить ваш дизайн (например, трудно создавать диагональные платформы) и может сделать анимацию очень скудной (например, ноги ваших персонажей фактически не касаются платформы). Эта опция может работать ИМХО для приключенческих игр, подобных Zelda, но не для экшенов.

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

Я бы не удивился, если бы были доступны 2D игровые движки, которые предоставляют такую ​​возможность, поскольку, безусловно, есть 3D движки, которые это делают. На самом деле, вам может оказаться проще использовать существующий движок 3D-игр и использовать его для рендеринга 2D.

Answer 2

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

colour |      z map         | collision
-------|--------------------|---------------
black  | draw dizzy infront |  collide
white  | draw dizzy behind  |  don't collide

Хранение этих монохромных изображений экономит много памяти.

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

Answer 3

Эта конкретная игра представляет собой игру на основе тайлов с идеальным столкновением пикселей. Столкновение контролировалось одним битом в цветном байте плитки (яркость), и вы также можете отразить плитку, установив мигающий бит цвета.

Однако плитки можно размещать только в четных координатах x, y (я подозреваю, что это было сделано, чтобы немного помочь системе столкновений.)

Система столкновений включала постоянную проверку вокруг героя. Правила были примерно: - Если он находит ряд пикселей без столкновения ниже героя, он понижает героя на 1 пиксель. - Если есть пересечение столкновения с героем, оно поднимает героя на 1 пиксель. - При движении влево или вправо, он проверяет в этом направлении, и если: - если обнаружит стену (высота столкновения более 4 пикселей), запретить движение в этом направлении; - если он обнаружит поле для набора высоты (высота столкновения до 4 пикселей), разрешите движение в этом направлении. - Если имеется достаточный запас высоты, можно прыгать, иначе остановитесь на последней возможной свободной позиции.

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

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

Аналогично этой демонстрации: http://games.catevaclickuri.ro/