Привет любителям консолей!

Пока все хотят PC или Xbox, потому что на них поддерживается куча игрушек, раньше тренд задавала Sega. Так Dreamcast VMU стал первым, кто внедрил второй экран прямо в геймпад. Зачем, разве не хватало одного в то время? Но плюсы в виде мини‑игр, телеметрии и скрытого HUD, заинтересовали публику.

В наши дни — companion‑приложения, OLED‑панели в мышах и клавиатурах, а также веб‑интеграции с играми. Разберёмся, как работал VMU, что используют разработчики для вторых экранов и как вы можете добавить companion‑функционал в свой проект. Детали найдёте внутри.

Архитектура VMU: железо и протокол

Давайте посмотрим, что он из себя представляет.

Если разобрать VMU от Sega Dreamcast, внутри оказывается не просто кусок пластика, а вполне себе мини-компьютер образца 1998 года. 

На плате — 8-битный микроконтроллер Hitachi HD647180, который, если разобраться, не просто «глупый чип», а хитрая архитектура, близкая к Z80, но с упором на экономию энергии и минимум железа под крышкой. LCD-дисплей 48×32 пикселя — это, конечно, не Retina, но для игр уровня Tamagotchi или отображения здоровья в Resident Evil вполне. 

Память 128 КБ SRAM, даже сейчас не всегда понятно, куда всё умещалось, но для сейвов, мини-игр и разных мелочей этого хватало.

Геймпад и Dreamcast связывала физическая шина (4-контактный разъём). Обмен данными между ними осуществлялся по протоколу, который часто называют «фейк-SPI» — т. е. полусинхронный, pseudo-I²C протокол с четырьмя сигнальными линиями (VCC, GND, DATA, CLK). Это не совсем стандартный I²C/SPI, а именно внутренний протокол Sega для низкоуровневой передачи данных.

VMU выглядит как флешка с некоторым объёмом данных, но это скорее почти самостоятельное устройство — правда, с запасом батареек на пару часов автономной работы. Хотя бы не по проводу, и то хорошо.

VM/PDU — это пакеты для обмена с консолью. Заголовок определяет тип команды, а дальше идёт адрес, данные и контрольная сумма. Всё синхронизируется по тактам контроллера, и если что-то идёт не так — VMU просто отваливается, никакой связи без правильного старта.

Кстати, приятная фича, архитектура протокола позволяет определять, что именно подключено — геймпад, VMU или вообще неизвестное устройство. Это, конечно, не USB, но в конце 90-х хватало.

Организация памяти и загрузка мини-игр

Memory map VMU делится на логические области:

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

• Пользовательская память: сейвы (по 512-640 байт на слот), таблицы рекордов, скриншоты.

• Executable Region: область для загрузки коротких бинарников, мини-игр (до 24 КБ).

Из главного меню или с консоли можно запустить игры, интересно, что при запуске она занимает кусочек SRAM. В целом ничего необычного, ещё вдобавок экран переходит в тёмный режим и отключается всё ненужное, во благо экономии, конечно же.

Теперь про сохранения. Каждое содержит важные данные: тип приложения, когда его сделали, CRC, и сам блок данных. Это значит, что можно играться с разным ПО, копировать и передавать.

Современные «вторые экраны»: стек технологий

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

Для этого нужно обеспечить связь между игрой и вторым экраном. Тут нам поможет WebSocket — технология, которая даёт двусторонний канал, как говорится, в real time. Задержка терпима, если вы не киберспортсмен (судя по всему, ещё и ретро), 50 мс даже на обычном Wi-Fi практически незаметна.

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

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

Для современных проектов эти «проблемки» терпимы, если сразу продумать, как серверная часть будет справляться с наплывом людей и возможными сбоями. Если же ваш сервис работает с практически не меняющимися данными (например, обычный сайт-визитка или интернет-магазин с постоянным ассортиментом), то WebSocket — это стрельба в небо. Тут хватит обычного HTTP.

А теперь ситуация, нет доступа в интернет или просто нужна автономность, выручает старый добрый Bluetooth Low Energy (BLE). Технология для компактных устройств для экономии энергии: например, можно выводить на телефон статус здоровья героя или управлять настройками игры прямо с телефона через Unreal Engine. BLE позволяет как отправлять данные пакетами (например, раз в несколько секунд), так и мгновенно уведомлять о событиях — скажем, когда у игрока заканчиваются жизни. 

Пропускная способность у BLE скромная (размер пакета — до 247 байт, скорость зависит от расстояния и версии Bluetooth), поэтому для серьёзной графики или видеопотоков он не подойдёт, а вот для простых HUD-элементов — самое оно. Кстати, недавно у меня выходила статья про то, как Bluetooth выжил после самых громких дыр.

Сейчас второй экран — это целый технологический стек.

Само приложение чаще делают на React Native или Flutter — так оно сразу работает и на Android, и на iOS. Помимо этого есть готовые SDK Для быстрой сборки интерфейсов, а поддержка гибридных схем позволяет разделить логику между телефоном и облаком.

Смотря назад, где для развёртывания нужно было куча железа, видна разница. Сейчас достаточно обычного смартфона, стандартных протоколов и облачных сервисов. От игр и стримов до интерактивных инсталляций, музеев и киберспорта.

API и SDK: что дают производители железа

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

Razer Chroma SDK и OLED API

Razer, например, предоставляет Chroma SDK — RESTful API, с которым можно управлять подсветкой и даже OLED-экранами на их устройствах. Для подключения к API достаточно отправить POST-запрос на локальный сервер, после чего можно отправлять команды на изменение изображения на дисплее. Пример на C++: выводите на OLED-мышь строку статуса (например, уровень здоровья, время, никнейм игрока) или простую мини-графику (график FPS, заряд батареи).

Главное — уложиться в 15 секунд, иначе сервер разорвёт связь из-за таймаута соединения.

Elgato Stream Deck SDK

Это уже не просто набор кнопок, а умная программируемая панель с мини-дисплеями на каждой клавише. Для интеграции собственного функционала есть Stream Deck SDK на JavaScript/Node.js, с помощью которого разработчик может создавать плагины под свои задачи: выводить на кнопках иконки, тексты, индикаторы, анимацию и вообще всё, что нужно для конкретного сценария — хоть спектр музыки, хоть статус сервера, хоть управление стримом.

Microsoft XInput + DirectInput и расширения для DualSense/DualShock

У Microsoft подход традиционно платформенный: XInput и DirectInput — это стандартные API для работы с геймпадами на Windows. Но если речь о каких-то новых контроллерах с OLED-экраном (например, DualSense), то здесь уже специфические решения — например, для вывода уведомлений, статуса батареи, индикаторов или даже кастомных изображений прямо на встроенный дисплей контроллера. Работа с таким железом требует уже не только знания стандартных API, но и документации от производителя, зато позволяет выводить на контроллер уникальный контент.

Также были такие экземпляры, как Wii U. Наличие карты и инвентаря на экране было довольно круто в таких играх, как Windwaker. Но большую часть времени это казалось лишней морокой — всё время таращиться вверх-вниз, когда другой экран можно было бы просто включить на телевизоре. Проблем это особо не решало. В итоге большинство игр просто забили на экран геймпада. А ещё проблемы с батареей.

Что это даёт на практике — производители железа открывают набор инструментов для создания интерфейсов. Можно писать свои плагины, выводить телеметрию, управлять подсветкой и экранами, интегрировать железо в рабочие процессы или что-то из забавного, например, танцующий рикрол. Благодаря API и SDK современные «вторые экраны» становятся не просто аксессуаром, а частью экосистемы, где функционал ограничен только фантазией разработчика — и возможностями самого железа.

Интеграция в игровых движках

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

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

Можно собрать стек ScriptableObject, а сверху Node.js на Unity, или же Unreal Engine с внешними API и кастомными вебами. Blueprint-графы в Unreal Engine, ускоряют прототипирование UI.

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

Современные — что стало 

Сейчас идея второго дисплея используется совсем иначе: в форме портативных мониторов, AR‑очков, контроллеров с экраном и пультов для стримеров. Итак, примеры:

Портативные мониторы

Компактные дисплеи USB‑C/HDMI, обычно 1080p/2K, с частотой 60–144 Гц и низким откликом.
Jsaux FlipGo — два QHD‑экрана в вертикальной раскладке, поддержка FreeSync, подходит как геймерам, так и стрим‑энтузиастам. И чат почитать во время трансляции и ютуб смотреть во время работы/игр.

AR/VR очки с экраном

Xreal One AR glasses — устройство с micro‑OLED дисплеем, создающим эффект большого экрана перед глазами при подключении к Steam Deck и другим устройствам. Удобно и портативно, но ограничено углом обзора и стоит дорого (~$499). 

Двухэкранные ноутбуки

HP Omen X 2S — 15,6″ ноутбук с дополнительным сенсорным экраном над клавиатурой, что позволяет отображать Discord, карту игры или стрим, без свитчинга основного экрана — современная адаптация VMU‑концепта.

Портативные игровые консоли

Устройства вроде Steam Deck OLED, ROG Ally X, Lenovo Legion Go, MSI Claw 8 AI+ — позволяют играть в поездках, подключаться к внешним экранам или трансляциям; сами по себе становятся центром геймплей‑экосистемы, и часто совмещают экраны, управление и стриминг. 

Почему это востребовано

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

Современные companion-приложения предлагают дополнительные активности: фоновые питомцы, напоминая, сводка уведомлений и реалтайм-вызовы — то есть, расширяют вовлечённость без активного геймплея.

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

А ещё, подходы к DevOps и CI/CD используют companion'ов для авто-теста, деплоя и обновлений. Это касается не только релизов, но и горячих фиксов, экспериментов с функционалом и даже A/B-тестов UI/UX прямо «на живых» пользователях.

В эпоху VMU у второго экрана не было базовых практик или правил пользования — пользователи только учились с ним работать. Сейчас у них свои, часто очень жёсткие представления о том, что удобно, а что нет. Это также подчёркивает нынешний рынок, что всё стало похоже друг на друга, т. к. выживает наиболее «удобная» модель.

Например, никто не будет вводить текстовые команды по десять раз за матч, если есть шанс «жестом» передать сообщение в чат. 

Визуально второй экран — это скорее расширение соц-функциональности игрока, а не технический интерфейс. 

Поэтому ошибкой будет зашивать туда что-то, что не работает «в один клик» или требует дополнительных шагов — внимание мгновенно улетучивается.

Практика показывает — чем больше пользователь может настроить под себя: что и где показывать, как реагировать на события, — тем выше вовлечённость. Но универсальные решения всегда требуют меньше ресурсов на поддержку. Найти баланс между тем, чтобы дать свободу, и тем, чтобы не превратить второй экран в конструктор Lego (где всё равно никто ничего не соберёт), — это отдельное искусство.

Есть ли будущее у «вторых экранов» или всё же это очередная ветвь модификаций ради отличий. Может, у вас уже был опыт такого функционала в проектах, делитесь мнением в комментариях!

© 2025 ООО «МТ ФИНАНС»