Ни для кого не секрет, что разработчику мобильных приложений необходимо учитывать разнообразие дисплеев, используемых в смартфонах и планшетах.
Существуют разные подходы к решению этой проблемы для корректного отображения интерфейсов мобильных приложений на экранах разного разрешения и соотношения сторон.
Хочу представить вашему вниманию свой подход, который я использую при разработке игровых приложений в альбомной ориентации.
Если посмотреть на тенденцию последних лет в выборе экранов производителями смартфонов для своих моделей, то нетрудно заметить стремление увеличить высоту дисплеев.
В этом есть доля мудрости.
Пользователям становится гораздо удобнее работать со многими приложениями в книжной ориентации, удобнее просматривать веб-сайты.
Благодаря вытянутому экрану на нем можно разместить гораздо больше информации и уменьшить необходимость часто прокручивать контент вверх или вниз.
Но есть достаточно большая категория приложений, требующих альбомной ориентации экрана, например, многие игровые приложения.
В этом случае необходимо приложить дополнительные усилия, чтобы игра выглядела корректно на экранах с разными соотношениями сторон.
В настоящее время формат дисплея 16:9, пожалуй, самый распространенный, но не единственный.
На рынке представлено множество моделей, в которых используются экраны с соотношением сторон 18:9; Новинки Apple оснащены дисплеями с соотношением сторон 19,5:9. Но это не предел; В начале года Sony представила смартфон с экраном 21:9. А совсем недавно китайская компания Xaiomi анонсировала новинку с экраном 22,5:9. В то же время нельзя сбрасывать со счетов наличие большого количества моделей планшетов с экранами 4:3. Если последний формат представлен как 12:9, то нетрудно заметить интересную особенность: в альбомной ориентации высота экранов разных пропорций кратна 9, а по горизонтали их кратность может различаться почти в два раза.
В поисках оптимального решения этой проблемы я наткнулся на предложение разместить основные игровые элементы в области, соответствующей экрану наименьшей относительной ширины в альбомной ориентации.
Понятно, что при таком подходе следует ориентироваться на формат 4:3. При запуске игры на смартфонах с другими форматами дисплея было предложено заполнять дополнительное пространство фоновым изображением.
Такой подход вполне разумен, но лишь с небольшой разницей в пропорциях экрана.
Например, если игра была создана для экрана 16:9, то она будет работать и для дисплея 18:9. Но в случаях, скажем, 22,5:9 и 4:3 — это маловероятно.
Еще я наткнулся на предложение использовать «резиновую» верстку, при которой размеры игровых элементов адаптируются к размерам дисплеев.
Но это также не решение; во многих случаях форма таких элементов искажается.
Мой подход к верстке
После серии экспериментов я нашел подход, который прекрасно работает на практике.Вполне возможно, что я изобрел «велосипед», но найти его мне не удалось.
Повторюсь, предлагаемое мною решение разрабатывалось под конкретные задачи и не факт, что оно универсально.
В игре Прыгающий Доджем что я сделал, используя Фреймворк LibGDX , к центру экрана применяется ортогональная проекция камеры.
Поэтому было решено использовать эту точку как единую точку отсчета при размещении всех игровых элементов.
Но это не догма, некоторые элементы были привязаны к границам экранов, что оказалось удобнее и давало лучший визуальный результат. При разработке в качестве базового размера игрового экрана был выбран широко используемый формат 16:9 с разрешением 1920x1080. Большинство игровых элементов расположены от центра экрана в относительных углублениях со знаками плюс и минус.
На рисунке схематично показан принцип такого размещения на примере двух кнопок управления игровым процессом и надписи с фиксированным положением.
Но предлагаемый метод является лишь принципом; на практике такой подход не всегда оправдан.
Как вариант, можно унифицировать выбор коэффициентов относительного отступа, задав заранее заданные константы.
Допустим, мы хотим, чтобы края кнопок находились в пределах 5% от ширины и высоты экрана.
Если для левой половины экрана формула остается неизменной, то для правой половины нужно будет учитывать размер самой кнопки.
Такой подход позволил правильно расположить игровые элементы на экранах с разными пропорциями.
Например, вот скриншоты моей игры на разных дисплеях.
Для наглядности скриншот экрана 4:3 взят из эмулятора древней модели с дисплеем 320х240. 
На первом скриншоте с соотношением сторон 4:3 артефакт намеренно оставлен в правой части экрана.
Верхняя и нижняя правые кнопки были размещены с учетом относительных коэффициентов смещения от центра экрана.
Как видите, верхняя кнопка «не справилась».
Это связано с перерасчетом размера исходного изображения кнопки с учетом разрешения экрана.
Если не ввести этот коэффициент, то правый край кнопок в этой части экрана выйдет за его пределы.
Но поскольку размер кнопки уменьшился, а начало ее выходных координат осталось неизменным, визуально она оказалась «неудачной».
На этом скриншоте проблема решена за счет использования коэффициентов относительного смещения от границ экрана.
Теперь несколько скриншотов для экранов разных пропорций 
Соотношение сторон 16:9, экран 1920x1080. 
Соотношение сторон 18:9, экран 2880x1440. 
Экран с соотношением сторон 19,5:9, 2688x1242.
Смещение начала точки вывода большинства игровых элементов на представленных скриншотах осуществлялось, как говорилось выше, через относительные смещения от центра экрана.
А вот с пятью кнопками управления пришлось поступить немного по-другому, чтобы они всегда находились на своих местах.
Для них был установлен относительный отступ Kpadding по осям X и Y от границ экрана.
Поскольку игра создавалась для базового разрешения 1920x1080, для корректного отображения на дисплеях с другими разрешениями был рассчитан специальный коэффициент масштабирования, исходя из реального размера экрана и базового разрешения.
Этот коэффициент учитывался при расчете абсолютных смещений игровых элементов и их отображаемых размеров.
Я надеюсь, что эта статья поможет новым разработчикам игр и сэкономит им много времени.
Теги: #Разработка игр #Дизайн игр #Дизайн мобильных приложений #дизайн игр #размещение экрана #libgdx #leaping dodgem
-
Кармическое Развитие (Kdd)
19 Oct, 24 -
Azure-Iaas-Сборник №9 (Июль-Август)
19 Oct, 24 -
Json В Swift 2.0 Без Анестезии
19 Oct, 24 -
Mybatis И Osgi
19 Oct, 24
