Программирование логики отображения графики интерфейса

Программирование логики отображения графики интерфейса

Нарисованный и сверстанный интерфейс — это ещё не интерфейс. Нужна логика: какие данные откуда берутся, как они попадают на экран, как экран реагирует на изменение состояния игры, как работает навигация между экранами. Это программирование UI, и оно составляет треть времени разработки интерфейса.

Архитектура связи UI с игровой логикой

Главный архитектурный выбор — как UI узнаёт об изменениях в состоянии игры. Три основных подхода:

Observer / Event System — UI подписывается на события игровой системы: HealthSystem.OnHealthChanged += UpdateHealthBar. Слабая связь, можно легко переключать UI-реализации. Проблема: при уничтожении объекта до отписки — NullReferenceException. Обязательно отписываться в OnDisable() или OnDestroy().

Model-View-Presenter (MVP) — Presenter отвечает за связь между данными (Model) и отображением (View). View не знает про игровую логику, только про свои визуальные компоненты. Presenter знает обе стороны. Хорошо масштабируется, хорошо тестируется. Типичная реализация в Unity — абстрактный класс BaseView с методами Show(), Hide(), Bind(IModel model), и конкретные Presenter'ы под каждый экран.

ScriptableObject-based событийная система — все события как ScriptableObject с методом Raise() и списком слушателей. Популяризировано Ryan Hipple на Unite 2017. Удобно для небольших команд, легко дебажить в Inspector. Минус: при большом количестве событий становится сложно управлять зависимостями.

Для большинства проектов рекомендую MVP с EventSystem для кросс-модульной коммуникации. Это даёт читаемый код, предсказуемое поведение и хорошую тестируемость UI без запуска сцены.

Управление состояниями экранов

Screen Manager — типичная система, которая контролирует, какой экран открыт, и управляет переходами. Минимальная реализация: стек экранов (для Back navigation), словарь screenId → IScreen, методы Push(), Pop(), Replace().

Для мобильных платформ Android Back Button должен корректно обрабатываться через Application.exitCancellationToken или через Input.GetKeyDown(KeyCode.Escape) — при нажатии должен закрываться верхний экран в стеке, а не выходить из игры. Это то, что часто забывают при разработке и замечают при сдаче в Google Play.

CanvasGroup — инструмент для управления видимостью и интерактивностью группы элементов. canvasGroup.alpha = 0 скрывает визуально, но элементы продолжают получать события. Обязательно также выставлять canvasGroup.interactable = false и canvasGroup.blocksRaycasts = false при скрытии — иначе невидимые кнопки перехватывают клики сквозь них.

Кейс: инвентарь с drag & drop

Задача: drag & drop перетаскивание предметов между слотами инвентаря с поддержкой геймпада. На мышке — IBeginDragHandler, IDragHandler, IEndDragHandler. На геймпаде — совсем другая логика: курсорный режим навигации с выбором источника и цели через кнопки.

Реализация drag & drop в uGUI требует создания «ghost» объекта — копии перетаскиваемой иконки, которая следует за курсором через RectTransformUtility.ScreenPointToLocalPointInRectangle(). Ghost должен находиться в отдельном Canvas поверх всего остального (отдельный Canvas с Sort Order выше основного) — иначе иконка будет перекрываться другими элементами при перетаскивании.

Для геймпада реализовали отдельный режим: первое нажатие A выбирает слот (подсвечивается selected state), навигация D-pad перемещает виртуальный курсор между слотами, второе нажатие A завершает перетаскивание. Два режима управления — два разных конечных автомата в одном InventoryController.

Работа с async/await в UI-логике

Современная Unity-разработка всё активнее использует async/await вместо корутин. Для UI-логики это особенно удобно при работе с сетевыми запросами, загрузкой данных, ожиданием анимации перед переходом экрана.

Главная ловушка async в Unity: операции продолжаются даже после уничтожения объекта. await Task.Delay(2000) в методе кнопки — и через 2 секунды код продолжает выполняться, обращаясь к уже уничтоженным компонентам. NullReferenceException гарантирован. Решение: проверка this == null после каждого await (Unity переопределяет оператор == для UnityEngine.Object), или использование CancellationToken, который отменяется в OnDestroy.

Второй нюанс: async-метод, брошенный без await (fire-and-forget), не обрабатывает исключения. LoadUserData() без await — исключение внутри метода просто проглатывается, пользователь видит пустой экран, логов нет. Для fire-and-forget методов обязательно добавляем глобальный обработчик через TaskScheduler.UnobservedTaskException или оборачиваем вызов в try-catch внутри самого метода.

UniTask (Cysharp/UniTask) — существенно лучший вариант, чем стандартный Task для Unity. Работает без heap allocation для большинства операций, интегрируется с PlayerLoop Unity, поддерживает UniTask.Delay с привязкой к PlayerLoopTiming (Update, FixedUpdate, LateUpdate) и корректно обрабатывает cancellation при уничтожении объекта через destroyCancellationToken. На проектах с активным использованием async это снижает GC Alloc на 60–80% по сравнению с System.Threading.Tasks.

Логика отображения данных: типичные проблемы

Обновление UI каждый кадр — антипаттерн. healthBar.fillAmount = player.health / player.maxHealth в Update() работает, но пересоздаёт mesh для Image компонента каждый кадр даже если значение не изменилось. Правильно: обновлять только при изменении данных через event или property с setter.

Строковая конкатенация в Update — хуже. levelText.text = "Level: " + player.level создаёт новую строку каждый вызов, провоцируя GC Allocations. Используем string.Format() или StringBuilder для часто обновляемых текстов. В TextMeshPro есть SetText(string, float) — перегрузка с float-аргументом, которая форматирует число без GC allocation.

Z-fighting кнопок: два Button'а с одинаковым Sort Order в одном Canvas, один поверх другого. EventSystem отправляет событие на верхний по иерархии, но если Raycast Target включён у обоих — клики могут проваливаться. Проверяем через UI Debugger (правый клик в EventSystem → UI Debug).

Отображение Loading State: при ожидании ответа от сервера UI должен блокировать повторные нажатия. Типичная ошибка — просто показать Spinner и забыть отключить кнопку. Правильно: блокируем CanvasGroup.interactable = false для всего экрана + показываем Loading Overlay + в finally блоке async-метода восстанавливаем interactable = true. Иначе при медленном соединении пользователь успевает нажать кнопку несколько раз.

Процесс и сроки

Разработка начинается с архитектурного решения: выбор паттерна связи с игровой логикой, определение Screen Manager архитектуры, согласование интерфейсов между UI и игровыми системами. Затем — реализация базовой инфраструктуры (Screen Manager, Base View, Event Bus). Дальше — поэкранная реализация с юнит-тестами для Presenter'ов. Финал — интеграционное тестирование на устройствах.

Стоимость рассчитывается индивидуально после анализа требований к игровой логике и платформам.