Как сохранить видимость элементов управления питомцем и самого персонажа в компактном игровом интерфейсе

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

Прежде чем размещать элементы управления, выделите четкую визуальную область для персонажа. Следите за тем, чтобы ключевые детали его силуэта и мимика оставались открытыми, и не размещайте поверх них кнопки или подписи. Если действие требует прямого касания питомца, оставьте эту область взаимодействия свободной; если элементы управления располагаются поверх игровой сцены, убедитесь, что они не перекрывают ту часть персонажа, которую игрок должен видеть. В рекомендациях Apple по игровому управлению советуют сокращать количество виртуальных элементов управления там, где их функцию может выполнять прямое взаимодействие с игровыми объектами (Game controls).

Группируйте часто используемые действия там, где до них легко дотянуться, а вторичные действия располагайте дальше или прячьте в меню. На сенсорном экране избегайте скопления кнопок в той области, где рука игрока перекрывает питомца. Apple рекомендует располагать часто используемые сенсорные элементы управления в зоне досягаемости большого пальца, а второстепенные — ближе к верхней части экрана; в руководстве также упоминается необходимость учитывать удобство досягаемости и границы устройства. Рассматривайте эти советы как отправную точку для тестирования на целевом устройстве и в нужной ориентации, а не как раз и навсегда заданную схему для любой игры.

Делайте видимый значок компактным, не уменьшая при этом саму область касания. Apple рекомендует минимальный размер 44 на 44 пункта для часто используемых элементов управления и 28 на 28 пунктов для менее важных элементов на своих платформах. Android рекомендует не менее 48 на 48 аппаратно-независимых пикселей для интерактивных областей касания. Это параметры, специфичные для каждой платформы, поэтому используйте соответствующие единицы измерения и рекомендации конкретной ОС, а не считайте эти цифры взаимозаменяемыми (Apple game controls, Android accessibility guidance). Оставляйте достаточные расстояния между кнопками во избежание случайных нажатий, особенно если два действия приводят к совершенно разным результатам.

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

Проверяйте читаемость текста и значков как на светлых, так и на темных участках сцены. Контраст, работающий на одном фоне, может исчезнуть, когда питомец переместится или изменится сцена. Что касается текста, руководство W3C WCAG устанавливает коэффициент контрастности 4,5:1 для обычного текста и 3:1 для крупного. WCAG относится к веб-контенту, а не конкретно к играм, но приведенные в нем пороговые значения контрастности могут служить полезным ориентиром при проверке текста интерфейса на меняющемся фоне (W3C contrast guidance). Не полагайтесь только на цвет для обозначения недоступного действия: визуально меняйте также его подпись, форму или состояние.

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

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

Проектируйте интерфейс с учетом полезной площади, а не просто внешнего прямоугольника экрана. Вырезы, отверстия камер, системные панели и области жестов могут накладываться на важные элементы управления у краев. В руководстве по верстке Apple безопасные зоны (safe areas) описываются как области, помогающие изолировать контент от перекрытия элементами интерфейса и аппаратными особенностями устройства. Android точно так же рекомендует учитывать отступы для системных панелей, жестов и экранных вырезов, удерживая критически важные элементы вдали от вырезов (Apple layout guidance, Android edge-to-edge guidance). Фоновый арт может растягиваться до самых краев, в то время как интерактивные элементы должны оставаться в пределах отступов.

Не стоит полагаться на то, что один компактный вариант компоновки подойдет для любого соотношения сторон. Привязывайте элементы управления к полезной площади и позволяйте отступам или группировке адаптироваться при изменении доступной ширины. В руководстве Android по играм на Unity рекомендуется использовать API безопасных зон и поддерживать различные размеры дисплея и соотношения сторон. Тестируйте портретную или альбомную ориентацию, только если игра их поддерживает, и повторно проверяйте интерфейс после поворота, изменения размера окна или складывания устройства, если такие конфигурации предусмотрены (Android guidance for Unity games on large screens).

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

Используйте краткий контрольный список для каждого поддерживаемого макета:

• Питомец остается видимым во время основного действия, включая его мордочку и другие важные детали.

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

• Подписи и важные индикаторы состояния остаются читаемыми при смене фона сцены.

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

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

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

• Apple Developer, Game controls

• Apple Developer, Layout

• Android Developers, Make apps more accessible

• Android Developers, Edge-to-edge design

• Android Developers, Make your Unity game great on all form factors

• W3C Web Accessibility Initiative, Understanding Success Criterion 1.4.3: Contrast (Minimum)