размер персонажа для 2d игры
Советы по пропорциям и масштабу в играх
Вы создаёте новый хит и хотите, чтобы ваши персонажи вписывались в игру? Многие разработчики часто испытывают проблемы при подборе пропорций отдельных персонажей и соотношений между персонажами и окружением. Вы можете воспользоваться подходом, описанным в статье.
Очевидно, если в вашей игре нет персонажей, этот пост может быть бесполезен для вас (но может быть, он пригодится вам в следующем проекте). Такой подход не ограничивается гуманоидными песонажами и может применяться к антропоморфным и неодушевлённым объектам.
Шаг первый: определитесь с размером тайлов
Подбор размера тайлов — это отдельная задача, решаемая на ранних этапах разработки игры. Тайлы могут измеряться в единицах измерения мира (дюймы, метры и т.д.) или в пикселях.
Если в вашей игре нет сетки тайлов, можно создать черновой макет и использовать соотношения размеров для первоначальной настройки проекта. В моих примерах я воспользуюсь изометрической сеткой, но тип проецирования ни на что не влияет.
Вопросы, которые нужно задать:
После выбора самого подходящего размера тайла можно перейти к персонажам.
Шаг второй: считаем по головам
Сколько голов помещается в вашем персонаже?
Иллюстрация Эндрю Лумиса (Andrew Loomis)
Небольшая справка: реалистичные взрослые персонажи имеют рост в 7-8 голов. Если в ваших персонажей по высоте помещается 8 или больше голов, то они будут напоминать греческих богов или супергероев.
Но мы не будем обсуждать стиль или рост. Рост относителен, два персонажа с одинаковыми пропорциями могут быть разного роста.
Любой стиль может быть адаптирован под различные пропорции головы и тела.
Иллюстрация Гарона Россиньоля (Garon Rossignol)
Основное, что нам нужно здесь учесть — это соотношение размеров головы персонажа и остальной его части. Например, при создании персонажа высотой в 8 голов можно сказать, что его тело в 7 раз крупнее головы. Бóльшая часть коммуникативной информации и деталей передаётся через тело, а голова и лицо имеют вторичную роль. Я не хочу сказать, что голова не важна: мы обычно всегда рисуем первыми лица и руки (и некоторые другие выдающиеся части тела). Но в силуэте высотой в 8 голов детали и выражения лица будут излишними.
«A» — лицо и тело чётко видны.
«B1» — тело занимает больше пространства, когда персонажи в высоту 8 голов. Детали лица трудно считываются.
«B2» — если в вашей игре необходимо показать эмоции персонажей с реалистичными пропорциями, нужно будет воспользоваться крупными планами.
Левый край: преувеличенные эмоции, «мультяшные» движения, игривое настроение.
Правый край: слабовыраженные эмоции, реалистичные движения, серьёзное настроение.
Большинство анимированных персонажей относится к категории «2-6 голов». Хотя персонажи высотой 8 голов тоже могут быть гиперболизированными и шутливыми, чаще всего они будут относиться к категории серьёзных и реалистичных. Персонажи выше 8 голов тоже могут быть игривыми, но, повторюсь, тело будет привлекать больше внимания, чем голова и лицо.
Вопросы, которые нужно задать:
Широкие головы имеют бóльшую площадь поверхности, привлекают больше внимания и перекрывают бóльшую часть тела, когда камера направлена вниз. Если для визуального стиля требуются широкие головы, увеличьте рост на 1-2 головы и добавьте больше тела.
Обратное справедливо для ширины тела.
У вас широкотелые персонажи, которым нужно проявлять больше эмоций? Увеличьте размер головы.
Запомните важное правило: персонажи с небольшим телом можно делать значительно крупнее на экране, они могут выражать больше эмоций и обладать большей артистической свободой и искажённостью. Это позволяет разместить в пространстве экрана больше объектов и информации.
(© Microsoft)
В Age of Empires выражения лиц не важны. Отдельные юниты слабо различаются.
(© Beeline Interactive)
Выражения лиц важны в Smurfs’ Village, и ещё важнее в Minions Paradise. На экране персонажи (и их головы) выглядят больше.
(© EA)
Шаг третий: относительный масштаб и соотношения
Итак, у нас есть персонажи и размер тайлов. Насколько большими должны быть другие объекты относительно персонажей? Настал подходящий момент проверить, соответствуют ли выбранные визуальный стиль и пропорции требованиям игры.
В общем случае, если вы выбрали для персонажей реалистичные пропорции, нужно придерживаться реалистичных размеров зданий и объектов.
(© Firaxis Games)
(© Firaxis Games)
Можно допустить ещё бóльшие искажения, если вы создаёте игру «настольного» типа с иконографикой, похожую на Civilization и нацеленную на взрослую аудиторию.
Давайте пройдём по общему сценарию:
Поймите правильно, я не поощряю нумерологию или какую-нибудь мистику чисел. Можно выбрать любое соотношение размеров, которое вам покажется подходящим. В моих примерах я использую 1,618, но то же самое можно сделать и с другими соотношениями.
Используем 1:1,618 как отправную точку для определения границ высоты персонажей и зданий.
Слева: правдоподобие, важны здания. Справа: преувеличение, важны персонажи.
Очевидно, персонаж должен быть меньше зданий, чтобы заходить в них.
Можно также использовать соотношение для создания зданий и архитектурных элементов. Если в вашей игре нужны высокие здания, можно расширить выбранное соотношение на дополнительные этажи.
Используйте вариант «A» (простая конструкция), если персонаж должен пермещаться между этажами. Выбирайте «B» (упрощённое золотое сечение) и «C» (расширенное золотое сечение), если перемещение не требуется.
Не забывайте о дверных проёмах.
Убедитесь, что дверные проёмы достаточно велики, чтобы в них помещались персонажи.
Это не единственный способ решения проблемы масштаба, но надеюсь, он будет вам полезен.
Удачного вам гейм-дизайна!
Автор статьи Юрий Сиверс (Yuriy Sivers) — ведущий графический дизайнер в Kongregate. Он занимается гейм-дизайном, концепт-артом, иллюстрациями и анимацией.
Unity 2D: работа со спрайтами в разных разрешениях дисплея
Начиная с версии 4.3 в Unity появилась возможность работы с 2D графикой, большая часть новых стандартных решений мне пришлись по душе, потому что я как раз незадолго до этого обновления перешел с Corona SDK.
Но что меня не порадовало, так это отсутствие стандартных инструментов для оптимизации спрайтов под разные разрешения экранов, что имеет довольно таки существенное влияние на производительность на маломощных устройствах.
Конечно, можно использовать что-то похожее на 2D Toolkit для решения этой проблемы, но зачем платить 75$ если можно сделать все самому?
Cо слов пользователей официального форума Unity, разработчики в скором времени не планируют расширять 2D функционал, по крайней мере до релиза 5 версии Unity, и пока что пользователи должны самостоятельно решать данную проблему. Бороздя просторы интернета в надежде найти ответ, я набрел на интересный доклад одного из разработчиков Unity на летней Nordic Game Conference 2014, название говорит само за себя «2D issues and how to solve them». Пользуясь материалами этого доклада, я сделал свое решение проблемы поддержки дисплеев разного разрешения.
Для того чтобы начать, нам нужна только версия атласа спрайтов с самым высоким разрешением, остальные манипуляции с уменьшением качества атласов происходят внутри Unity.
Итак, на первом этапе мы должны организовать атласы спрайтов для разных разрешений: SD, HD, ultra-HD, у нас же будут использованы суффиксы 1x, 2x, 4x.
Берем атлас спрайтов, в нашем случае это ’spritesheet1@4x.png’, в инспекторе выбираем нужные параметры, режем атлас в Sprite Editor, если требуется. Создаем еще две копии атласа в Project Browser (cmd+D, ctrl+D) и переименуем их так, чтобы суффиксы в названии были ‘@2x’, ‘@1x’, меняем свойство Max Size на значение в 2 и в 4 раза меньше соответственно.
Спрайты должны находится в папке Resources, если таковой не имеется — создайте. Это позволяет загружать файлы с этой папки во время выполнения программы.
Обращу Ваше внимание на поля Pixels Per Unit и Format, первое поможет подобрать размер спрайтов под размеры сцены без изменения scale, а второе является очень важным для правильной передачи цвета, размера билда и использования ресурсов графического процессора. На эту тему есть замечательный мануал
Тут все просто, мы собираем игровой объект на основе атласа спрайтов с суффиксом ‘@2x’, добавляем анимацию и любые другие фишки, которые могут вам понадобится. Сохраняем объект как префаб.
Суффикс ‘@2x’ был выбран, потому что большая часть устройств имеют hd разрешение, нам не придется делать лишнюю работу в большинстве случаев.
Скрипт будет работать с любым количеством компонентов SpriteRenderer. Он не будет влиять ни на анимацию, ни на что другое, главное чтобы имена спрайтов в атласе и SpriteRenderer`е были одинаковыми. Данную особенность можно применять не только для смены разрешения спрайтов, но и для замены их на полностью другие, например при создании другого скина персонажа.
Основной принцип работы скрипта таков: у нас есть публичная переменная spriteSheet, в которой мы передаем имя атласа, в котором находятся спрайты нашего объекта.
С помощью метода GetQuality узнаем с каким дисплеем мы имеем дело (для моих целей было достаточно ориентироваться на высоту экрана).
Потом в методе ManageQuality, имея данные о разрешении экрана, загружаем в массив sprites все спрайты нужного нам атласа с правильным суффиксом. В массив renderers загружаем все компоненты SpriteRenderer, которые находятся в объекте. Ищем в массиве sprites спрайт по имени и присваиваем его спрайту компонента SpriteRenderer, если такой существует. Завершает все Resources.UnloadUnusedAssets (), этот метод выгружает из памяти неиспользуемые ассеты.
Также этот скрипт можно использовать для изменения всех спрайтов в сцене. Для этого создаем новый объект, например SpriteManager, и добавляем к нему данный скрипт, но с измененным определением массива renderers:
Спасибо за внимание, надеюсь статья была вам полезна.
Основы создания 2D персонажа в Godot. Часть 1: компилирование игрового движка, создание проекта и анимация покоя героя
Пару дней назад увидел статью о публикации исходного кода под свободной лицензией MIT игрового движка Godot и сразу решил поковыряться в нём.
Оказалось не всё так сложно, скорее забавно. В своей первой публикации хотелось бы рассказать о первых шагах на пути к созданию игрового платформера, и всех подводных камнях, о которые я чуть было не переломал пальцы за эти дни.
Если это кому-то интересно, добро пожаловать под Хабракат!
Встречаем: компилирование и установка godot на GNU/Linux x86, создание простейшей сцены и анимированного персонажа
Сразу определимся, чтобы не было недопонимания:
1) На написание статьи меня сподвиг Charoplet со своим циклом статей «2D персонаж в Unity 3D». Спасибо ему за это, творческих успехов и новых публикаций.
2) Опять же, для наглядности взял (без спроса) текстуры (персонажа) из его уроков. Надеюсь, меня за это простят.
3) На борту имею только GNU/Linux, x86 и amd64 соответственно. Под другие ОС достаточно скачать бинарные файлы с сайта создателей. Так как под amd64 всё уже есть, а под x86 предвидится в ближайшем будущем (автор обещал скомпилировать бинарные файлы как только сможет), я и решил что для 32-битных систем статья будет более актуальна и интересна.
Компиляция
Устанавливаем зависимости, если ещё нет в системе (Если что-то не получается, информация устарела, посмотрите на сайте разработчиков):
GCC or LLVM
Python 2.7+ (3.0 ещё не тестировался).
SCons build system.
X11 and MESA development Libraries
ALSA development libraries
Freetype
pkg-config
Пользователям Ubuntu:
Клонирование исходных кодов:
Можно сходить и приготовить чашечку чая. Компилирование — процесс не быстрый.
Чай приготовили, компиляция ещё идёт? Тогда можно сходить на сайт издателя и почитать документацию, скачать Демо и примеры, а так-же Шаблоны экспорта проектов под нужные операционные системы.
Первый запуск, создание проекта
В директории /bin появился бинарный файл godot. Достаточно просто запустить его.
Перед нами сразу же появляется диалоговое с проектами. Так как мы запустили в первый раз, оно будет пустым.
Давайте создадим свой первый проект.
Сначала я думал что у меня руки кривые. Пересобрал из git, запускаю — опять двадцать пять. Собрал на другой машине — всё заработало! На своей — нет. И тут до меня допёрло! Товарищи! Программа не понимает кириллицу! В общем переместил я всё в другой каталог, и всё заработало и на моей машине. Что ж, впредь будем осторожнее.
Ну вот и главное окно программы.
Для начала давайте создадим новую сцену. Сцена — это эпизод игры. Это может быть целый уровень. Заставка. Анимация персонажа. Задний план. Godot — программа редактирования сцен. Мы сегодня не будем углубляться в создание полнофункциональной игровой сцены, а просто создадим персонажа.
Создание игрового персонажа
Первое что надо сделать — это добыть спрайты. Нарисовать/скачать/украсть. Я пожалуй возьму из урока про Unity3D. Спрайты от Charoplet.
Качаем Idle.png.
Импортируем в Godot:
Указать какое изображение(я) куда импортируем
Указать степень сжатия
И нажать «Import». В Wiki есть более подробная информация об импорте текстур на английском. Рекомендую к прочтению.
Ну а мы довольные результатом пробуем создать персонажа.
Сцена персонажа
В верхнем правом углу в окошке Scene нажимаем на единственную активную кнопку «Add/Create a new Node», или сочетанием клавиш Ctrl+A создаём «Ноду». Я думаю самый близкий перевод — шестерня, но звучит не красиво. Пусть будет материал? Документ? Или так и оставить, — «Нода»? Буду рад комментариям.
В поиске «Search» вводим «Rigid», и «Node» отсортируются по названиям. Выбираем RigidBody2D.
Настраиваем параметры в меню Inspector ниже:
Mode: Character
Mass: 3
Friction: 0
Custom Integrato:
Да, она появилась! Теперь нам надо указать, что у нас тут аж целых 8 фреймов (Правда сами фреймы считаются с нуля, их количество считаем с единицы, привыкайте). Параметр Hframes, — Горизонтальные фреймы, ставим равным 8. И что мы видим?
На первом же (который нулевой) фрейме виден хвост капитана из следующего! Это возмутительно! Да что эти OKAM Studio о себе возомнили?! Даже количество кадров в раскадровке нормально посчитать не могут! Как они могут такие программы писать?!
Да? Промелькнула мысль? Нет, разработчики не виноваты. Виноваты мы. Поленились нарисовать свои спрайты. Взяли чужие — вот и расплата.
Персонаж на спрайте расположен криво. Будем править.
В GIMP’е оказывается делать/изменять/править спрайты не так уж и трудно. Выставляем сетку нужного размера (120 на 120 пикселей). И распихиваем кадры по местам. Готово. Скачать исходные файлы можно тут. Готовая текстура выглядит так:
Да, я склеил все анимации в одну картинку. Чтобы было проще работать дальше. Когда мы будем делать прыжки и бег/ходьбу.
Ок, перезаливаем. Указываем Vframes = 4; Hframes = 8
Наводим на RigidBody2D и переименовываем его в player. Так будет понятнее, не правда ли?
Ctrl+A — создаем «Node» «AnimationPlayer» и сразу же «Camera2D» чтобы не возвращаться. Переименовываем AnimationPlayer в anim, а Camera2D просто в camera. Так дальше будет проще. С камерой я думаю сразу догадались что делать. Больше пока её трогать не будем.
Самое время создавать анимацию! Делать это проще некуда! Выбираем anim, внизу слева появляется меню анимации.
Создадим анимацию. Слева внизу есть кнопка «Create new animation in player». Жмякаем. Называем idle.
Нажимаем на карандаш правее, и вот оно, меню редактора анимации.
Ставим Len(s) — длину анимации 1,1 (секунды), а Step(s) — шаг анимации, 0,15.
Выбираем опять на Sprite в окне Scene вверху справа.
Смотрим на Inspector — ищем переменную Frame. Она должна равняться нулю. Справа нарисован ключик. Нажимаем на него. Нам предлагают создать новую линию анимации «frame» для данного спрайта. Соглашаемся (Create).
Теперь всё просто. Нажимаем Ctrl + Right, выбираем следующую анимацию — нажимаем на ключик. И так далее. Всего должно получиться 8 синих точек, 8 кадров анимации. После этого можно нажать на плеере на play, и посмотреть что у нас получилось. Да, не забудьте зациклить анимацию. (Кнопка Enable/Disable looping in animation).
Так, 30% сделали. Теперь самое интересное.
Будем варить! кодить!
Переключаемся на вкладку скрипты.
Ну-с, поехали. Напоминаю что программа не понимает кириллицу. Поэтому комментарии к коду только в образовательных целях. Не пытайтесь их вставить в код. Ниже будет полный код без них.
Ну вот, а вы боялись.
var new_anim=anim
new_anim=«idle»
if (new_anim!=anim):
anim=new_anim
get_node(«anim»).play(anim)
Не забываем сохранить как player.gd.
Так. В принципе почти всё готово. Осталось самое главное:
Создание сцены
Не забываем сохранить сцену с персонажем. И создаём новую. Благо уже умеем.
Для начала создаём пустую «Node» — назовём её Scene.
Теперь к ней привяжем нашего игрока. Нажимаем на «плюс» и выбираем нашего только что созданного player.xml.
Сохраняем нашу сцену как scene.xml. И запускаем ещё раз. Если всё сделали правильно, то увидите потрясающую анимацию нашего Капитана!
Небольшое видео результата с бонусными задниками и землей под ногами:
Ну и в заключение. Как я писал выше, в ОС GNU/linux x86 на данный момент проект экспортировать нельзя. Авторы программы уведомлены. В скором будущем обещали решить эту проблему и скомпилировать не только бинарники для x86, но и Шаблоны экспорта. Также можете протестировать экспорт на другие ОС.
Ну а я, если получится, надеюсь продолжить цикл статей о создании 2D, а в будущем возможно и 3D игр на этом замечательном движке. Приятной пятницы, с Днём Компьютерщика, до скорых встреч!
Простые вопросы про разрешение и спрайты
Пытаюсь пилить ремейк одной NES игрухи, разрешение экрана 256х240, размер спрайта 16×16, потому что так изначально было в ковыряемой мной игре, да и арт, персанаж, враги, бонусы все в предлах спрайта 16×16.
Главный вопрос такой: платформы на которые нужно запрыгивать уже 16 пикселей, допустим 6 пикселей(растояние от края верха, до края низа), как поступают в таких случаях? отрисовывают в в спрайте 16×16 и не использумое пространство делают прозрачным. И все столкновения и физика, происходит между спрайтами 16×16 но добавляют или вычитают еще offset?
и еще вопросы:
1. По каким соображениям выбирают размер спрайтов? ведь я так понял можно 8×8, 16×16, 64×64
2. Что делают если спрайт 16×16,а к примеру персонаж больше (24×30)
С каких это пор спрайт на денди стал 16х16, а не 8х8?
1. Нет таких соображений, все эти фиксированные размеры обусловлены теми или иными ограничениями (аппаратными или программными). Если бы ты столкнулся с этими ограничениями, то вопрос бы разрешился сам собой, а раз ограничений нет, так и делай любой размер.
2. Делают для персонажа спрайт 24х30. На денди делали виртуально из нескольких спрайтов по 8х8 (лишнее не отбрасывалось).
Про коллизию с платформой, да можно рисовать спрайтом 16х16, а при просчете офсет делать.
Вообщем в игре которую ковыряю изначально было все 16×16, и вот нужно сделать платформы по уже
это схематично, красной рамкой обвел границы спрайта, то есть всю физики считаем как пересечения спрайтов, но и добавляем еще offset так?
Разрешение для фонов игр и всего 2D арт-контента
Как выбрать разрешение для фонов игр, персонажей и окружения в Unity?
Частый вопрос: «Я делаю 2D-игру в Unity для PC и мобильных: какое разрешение выбрать для своего контента?», «Какое разрешение для фонов игр, бэкграундов (backgrounds) выбрать?», «Как выбрать разрешения для разных элементов игры?». На эти вопросы нет простого ответа, который подошёл бы во всех случаях. Попробуем определиться, как лучше поступить в ваших проектах.
Договоримся о понятиях. Реальность такова, работая с Unity, мы часто в речи не переводим названия понятий, функций и т. д., а скорее транскрибируем. Например, редко можно услышать как Tilemap называют «Карта плиток», зато чаще «Тайлмап». При первом упоминании, я буду стараться приводить оба варианта, а дальше то, которое употребляется чаще.
В последние время, Unity работает над большим количеством фич, которые помогают создавать 2D игры в Unity: атласы спрайтов (Sprite atlassing), 2D физика, карты плиток (Tilemap) для прямоугольных, шестиугольных и изометрических миров, основанные на кривых формы спрайтов (Sprite shape), 2D анимация, и т. д.
Пиксели не главное!
Unity не выражает размеры объектов в пикселях и это может запутать художников, которые создают контент для 2D игр. Насколько большими изображения должны быть? Какое разрешение для фонов игр выбрать? Как обычно в разработке игр, ответ на этот вопрос «Зависит от…». Давайте рассмотрим несколько моментов, которые помогут выбрать решение.
Если ты пиксель-арт художник, должен предупредить: большинство советов не в полной мере применимы к тебе. В пиксель-арт графике используют очень низкое разрешение. Обычно нужно, чтобы оно было кратно 2х, 4х, 8х, или больше, чем оригинальное разрешение. Это означает, что один пиксель оригинального изображения отображается как квадрат 2×2, 4×4 или 8×8 реальных пикселей на экране.
Так что в целом, в пиксель-арте, тебе не нужно слишком сильно беспокоиться о разрешении экрана. Стоит сосредоточиться на арте, и ощущениях, которые вы хотите передать (old-school, NES-эра, новый пиксель-арт высокого разрешения и т. д.) и затем масштабировать его в несколько раз.
У Unity есть решение Pixel Perfect в виде пакета. Оно поставляется как простой компонент, который добавляется на камеру и будет делать тяжелую работу за тебя. Можешь быть уверен, что графика останется четкой и выровненной по сетке, с маленькими аккуратными пикселями на любом экране.
Масштабирование вниз, а не вверх
Прежде чем мы углубимся в рассмотрение вопроса о выборе разрешения, стоит помнить, что когда ты создаёшь контент, лучше выбрать более высокое разрешение, даже если на самом деле это не нужно для изображений, которые пойдут в игру. Ты всегда сможешь уменьшить разрешение графики, но не сможешь увеличить разрешение без потери качества. Например, когда выбираешь разрешение для фонов игр, начинать с высоты меньше 2160px точно не стоит.
Случаи бывают разные: возможно, тебе придется распечатать несколько артов для игры, или понадобится увеличить размер элементов на экране, или ты захочешь создать «HD-версию» своей игры для 4К мониторов позже.
По этим причинам, когда начинаешь работать над контентом, надо обдумать использование рабочих файлов, которые будут с большим разрешением, чем действительно нужно. При экспорте можно уменьшить их перед добавлением в Unity, или использовать параметры импорта, чтобы уменьшить их размер, перед импортом в проект.
Параметры импорта также позволяют определить максимальный размер и параметры сжатия для каждой платформы, например, вы можете иметь разный контент для разных разрешений на ПК и на мобильных устройствах, где дисковое пространство имеет решающее значение.
Совет: Unity предлагает способ объединить несколько спрайтов в один через атласы спрайтов (Sprite Atlases). Помимо того, что это способ сэкономить на размере текстур, атласы также предлагают единый способ управления максимальным размером, вместо того, чтобы устанавливать его индивидуально для каждого спрайта в проекте.
Определение разрешения для вашей платформы. Разрешение для фонов игр должно быть больше!
При определении размера контента, важно учитывать платформы и устройства, на которых выйдет игра. У людей очень разнообразные устройства и экраны, и они увидят игру в разных разрешениях и соотношениях сторон.
4K и Full HD
На момент написания этого поста, подавляющее большинство пользователей имеют 2 разрешения. В основном «Full HD» (1920×1080 пикселей, часто называют 1080p) и много 1280×720 (часто называют 720р). Небольшой процент людей также имеют мониторы 4K (3840×2160) или мониторы Retina на компьютерах Mac. Современный 15-и дюймовый MacBook Pro будет иметь максимальное разрешение 3360×2100. Это очень много пикселей!
Для телефонов тоже разброс огромный. Некоторые старые устройства могут быть менее 720 пикселей по вертикали, а некоторые будут достигать и 4K.
Retina (товарный знак Apple) и другие современные экраны с высокими разрешениями, в то время как их реальное аппаратное разрешение очень высокое (например 4К), могут симулировать пониженное разрешение (как правило, половину, например, Full HD, а не 4К), но потом, при рендере изображений и текста, используют вдвое больше пикселей, поэтому изображение отображается довольно чётко.
Примечание: DPI (точек на дюйм) или PPI (точек на дюйм, или пикселей на дюйм) это разные названия (взаимозаменяемы) от разных производителей. Означают они одно и то же: сколько пикселей содержит линия длинной в дюйм на экране. Традиционно, экраны имеют 72 DPI. Сегодня высокий DPI экранов, как правило, 144 точек на дюйм, но можно найти телефоны, которые могут похвастаться 400-ми точками на дюйм или более, они содержат много пикселей на относительно маленьких экранах.
Обдуманный выбор
Для этих экранов, у тебя есть два варианта. Первый: стремиться к тому, чтобы предложить впечатление от 4K в полном объеме. Недостатком является то, что производимый 4К-совместимый контент потребует много лишней работы. В этом случае, надо не забыть похвалиться в своих маркетинговых материалах :). Владельцы консолей, типа PS4 Pro и Xbox One X, которые совместимы с 4K, будут рады, что игра использует их оборудование на полную мощность.
Второй вариант: можно спроектировать игру для Full HD. Пользователи с более высоким разрешением мониторов не получат преимуществ от разрешения их экранов. Они будут видеть игру в Full HD качестве. Это не супер, но хорошее решение, если ты также пытаешься сохранить размер игры под контролем.
Суть такова: нужно выбрать максимальное разрешение, которого хочешь достичь (на основе текущих потребностей рынка, желания и сил), и установить его в качестве целевого для всего проекта.
Измерения на сцене в Unity
Unity измеряет расстояния и размеры просто в юнитах (unit), а не в пикселях. Хорошая практика, когда соответствие такое: 1 юнит (unit) в Unity = 1 метр. Например, модель среднего человека между 1,7 и 1,8 юнита в таком случае. Это не обязательно, но это будет гарантировать, что игры с физикой (3D и 2D) будут вести себя корректно. Потому что физика в Unity (по умолчанию) настроена использовать 1 юнит на метр. Также это будет хорошо для 3D освещения. Световые параметры рассчитаны на это и останутся верными реальности.
В 2D это правило размеров является менее важным, но хорошая практика, если используешь физику в своём проекте. Если используется тайлмап, неплохо сохранить масштаб 1 плитка (tile) = 1 юнит (unit), просто для простоты.
Камера в Unity
Теперь, когда мы закончили с единицами, перейдём к камере. Unity 2D камеры (ортогональные или, если хотите, ортографические, т. к. в Unity это просто камеры без перспективы) имеют параметр называемый «Размер» (Size), который определяет, сколько юнитов (будет удвоено!) поместится по вертикальной оси этой камеры.
С размером 5, мы получим вьюпорт (видимое пользователем поле), который имеет 10 юнитов Unity по вертикали. Горизонтальная ось будет просто следовать за вертикальной. Так как мы не знаем, каким соотношением сторон будет обладать экран пользователя. Но, это легко рассчитать: на обычном ПК или телефоне, с соотношением сторон 16:9, можно так: 10 (Вертикальный размер) x 16 / 9 = 17.7 (Горизонтальный размер)
Так мы знаем, что с этими параметрами, наш вьюпорт примерно 17.7 на 10 юнитов. На Маках (которые обычно 16:10) это будет 16 к 10 (т. е. меньше видно по горизонтали). На 16:9 телефоне, если держать его вертикально (так он становится 9:16), та же камера будет показывать только площадь 5.6 на 10 юнитов.
Примечание: мы не будем разбирать всё о соотношении сторон тут. Если ты стремишься сделать игру для разных пропорций, нужно не только думать о графике, но также нужно сделать много геймплейных ухищрений, чтобы убедиться, что игра не играется по-разному на устройствах с различными соотношениями сторон. Например, игрок в любой игре, которая прокручивается по горизонтали будет иметь преимущество на горизонтальных пропорциях, потому что игрок сможет увидеть больше опасностей впереди. Иногда сделать игру, которая прекрасно работает на горизонтальных экранах нельзя. Игроки получат рамки, черные полосы для заполнения пространства, которое нельзя использовать во время игры.
Пикселей на юнит
При импорте графики, спрайтов, Unity отображает параметр, называемый пикселей на юнит (PPU). Теперь, когда мы знаем о юнитах, всё должно быть очень понятно. Он выражает сколько пикселей вашего спрайта помещается в юните на сцене Unity, когда игровой объект в масштабе 1,1,1.
Скажем для примера, у меня есть спрайт камня 218 на 175 пикселей, и я задаю пикселей на юнит в 100, когда я перетащу спрайт на сцену, мой объект по умолчанию будет 2.18 на 1.75 юнитов, занимающих приблизительно одну пятую из 10 юнитов по вертикальной оси экрана.
Возьмём Full HD экран, как нашe тестовое разрешение. 1080 пикселей по вертикали, а камень менее пятой части экрана. Можно увидеть, как полупрозрачные камни помещаются больше, чем 5 раз на изображении выше. Мы используем 175 точек исходного изображения для отображения более чем 200 пикселей. Это означает, что мы будем иметь немного размытые камни.
Чтобы исправить это, у нас есть несколько вариантов: мы можем уменьшить масштаб камня в половину, сделать размер кадра камеры больше, до 10,8 (это приведёт к приближению) или мы можем изменить значение PPU спрайта до 108 (это произведёт тот же эффект, уменьшит камень на экране). Во всех трех случаях, если мы хотим, чтобы камень быть четким, он должен быть меньше.
Как определяется размер камеры и значение PPU? Для размера камеры, если мы импортируем нашу графику как 100 PPU, нам потребуется 10.8 камеры, потому что 10.8×100 равна 1080. Это позволяет нам охватывать всю высоту экрана. И наоборот, для расчета правильной PPU, где размер камеры остается на 5, если мы хотим охватить Full HD экран с 10 юнитами Unity по вертикали, то у нас 1080/10 = 108. Это количество пикселей, которые мы должны запихивать в один блок, если не меняем размер камеры.
Правила можно нарушать
Когда ты работаешь над игрой, опасно смешивать все настройки. Это может закончится тем, что ты запутаешься, и какая-то графика будет размыта. Хорошо придерживаться рекомендации: одна настройка PPU для большинства контента в проекте, и типовой размер камеры.
После, можно нарушить эти правила. Возможно в процессе тестирования выяснится, что твои фоновые изображения велики. Разрешение для фонов игр сложно подобрать сразу. Оставить тот же PPU не получится, иначе в итоге получатся огромные текстуры. В этом случае нормально уменьшить PPU для таких элементов и импортировать уменьшенные спрайты.
Предпросмотр игры
Unity приятно удивляет тем, что разрешение, которое видно через предварительный просмотр «Game View» довольно точное превью целевой платформы. Большинство вариантов, которые нужны, будут в верхнем выпадающем меню и слайдере рядом с ним.
Пропорции определяют соотношения между шириной и высотой, но они будут использовать текущее разрешение вашего вьюпорта «Game View», который, в свою очередь, зависит от вашего экрана. И они хороши для настройки пользовательского интерфейса и объектов на экране, но не для тестирования контента.
Пока отмечен флажок на чекбоксе Low Resolution Aspect Ratio будет имитироваться низкий DPI. Если отключишь его, он будет отображать стандартное разрешение и DPI твоего экрана.
Подстройка под разрешения, сильная сторона Unity для отображения окна точного размера.Можно расширить «Game View» или развернуть его на полный экран. При этом ползунок «Масштаб» (Scale) может подогнать высокие разрешения под твоё окно «Game View». Ещё можно добавить собственные разрешения и соотношение сторон.
Совет: надо помнить, что до конца основываться на том, что видно во вьюпорте не стоит. Всегда делая сборку игры, надо обязательно проверять на целевом устройстве или экране.
Итоги
Понятно, разрешение изображений, размер камеры и размеры экрана на котором будет игра, всё тесно связано. Не бывает одного размера пикселей или PPU, которые подходят для всех случаев. Исследуй целевую платформу, определяй нужное разрешение. Делай контент в более высоком разрешении в любом случае, это пригодится позже! А по необходимости, уменьшай перед импортом в Unity.
И последняя мысль. Возможно, что в твоей игре некоторые объекты иногда находятся в пониженном разрешении. Особенно, если много мелких деталей на экране. Может быть, прозрачные перекрытия, какой-то туман, дождь или пост-обработки поверх. Поиграй в игру на нормальной скорости и обрати внимание, видно ли это и будут ли какие-то проблемы со слегка размытыми изображениями? Если не видно разницы, то, возможно не стоит тратить дополнительные силы, дисковое пространство и лишние вычислительные мощности на визуализацию твоего контента в высоком разрешении.
Рисовать уровень целиком сложно не зависимо от того какое разрешение для фонов игр ты выбрал. Всегда есть возможность попробовать создать 2D-уровень основанный на картах тайлов (плиток). Система «Tilemap» отличный выбор для начинающих.