Масштабирование ассетов в 2D-игре

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

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

Конечно есть три вещи, кои вы ждете от собственного движка:

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

Предположим, мы используем движок Cocos2d-x и
станем использовать терминологию, принятую посреди разработчиков на нём. Cocos предоставляет
базовый набор инструментов, потому методы, описанные ниже, подходят и для
других 2D-движков.

Политика разрешения

На самом деле к разрешению она не имеет никакого взаимоотношения.
Тут дело в кадрировании.

Cocos2d-x механически
масштабирует всю сцену под размер кадра. Конкретно политика разрешения (Resolution policy) разрешает вам
определять, как конкретно сцена занимает кадр.

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

Неопасная зона в нашем примере занимает 480х320 единиц (units), на экране в 570х360
единиц. Не пикселей, единиц. Соотношение сторон здесь — 1,5f. Но как мы можем быть в этом убеждены?

Мы вычисляем опорную ось (reference axis), исходя из соотношения сторон
монитора. Затем мы избираем фиксированную высоту либо фиксированную ширину,
исходя из опорной ости. Если опорная Y, то фиксированной становится высота, в неприятном случае —
ширина.

Размер композиции

Для того, чтоб Cocos сумел «подогнать» сцену под размер
кадра, движок должен «понимать», что конкретно мы считаем «сценой». Это и конечно есть
размер композиции (Design Size).
В нашем случае размер композиции — это величина безопасной зоны.

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

Итак:

• Cocos масштабирует под размеры монитора;
• политика разрешения показывает, «как» подстраивать под размеры монитора;
• размер композиции показывает, «что» подстраивать.

Поддержка нескольких разрешений

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

Более подходящий размер мы избираем в зависимости от
размера монитора, заданного опорной осью. В пикселях. После этого довольно
добавить подходящую директорию в «Resource Search Path»
в движке, опуская другие, чтобы они даже не были видны.

Фактор масштабирования контента

Мы также добавляем фактор масштабирования к каждой директории
для того, чтоб движок понимал, как ассеты
соотносятся с размером композиции. Это просто напросто. Например, если «средний» ассет в
два раза больше значения размера композиции, то значение масштаба — 2.

На этом шаге мы можем запамятовать о выборе ассетов, разрешении,
вариантах PPI, retina-мониторах, необычных
соотношениях сторон и прочем. Мы просто напросто «представляем», что размер монитора —
480х320, когда пишем код. За исключением тех случаев, когда вы желаете добавить декоративные
элементы за пределами безопасной зоны.

#арт