Многие слышали про квесты в реальности — перенесенные в наш мир игры жанра escape the room. Решаешь головоломки, получаешь ответы, проходишь на следующий этап. Закончить нужно за час, в итоге открывается дверь на выход. Но немногие знают, как они устроены внутри. В этой статье мы заглянем за кулисы одного из таких квестов, а также сравним его с другими в техническом плане.

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

Стандартный подход

Логически сценарий квеста делится на задачи. Например, заказчик хочет, чтобы «ввел код в клавиатуру ? загорелась лампочка». Соответственно, задача для техника здесь — сделать клавиатуру, которая зажигает лампочку при вводе правильного пароля. На ум сразу приходит Arduino, которая контролирует лампочку и клавиатуру. Так обычно и делается.


Стандартная архитектура

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

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

Простой пример: задача готова. Но требуется поменять цвет на управляемом прожекторе. Для этого нужно идти в то место, где установлена ардуина, подключать ноутбук, искать код к задаче, менять его, загружать, а потом тестить. Хорошо, если получится с первого раза. По моему опыту не редки случаи, когда такие, казалось бы, элементарные изменения приводили к серьезным последствиям: случайно задев какой-нибудь провод, рушится вообще вся задача или горит компонент. Квест останавливается, у команды истерика.

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


Кошмарный сон техника

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


Реализация одной из задач в одном из квестов. Сверху в центре ардуина.

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

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

Централизованный подход

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

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



В нашем квесте используется такая архитектура. Постараюсь рассказать поподробнее, как она реализована, и какие трудности возникали при разработке.

Реализация

Для начала список периферии:

• Управление GPIO (свет, замки).
• Информация с GPIO (кнопки, датчики)
• Светодиодные RGB-прожекторы
• Мониторы, показывающие видео синхронно (видео-стена) с возможностью менять скорость и добавлять текст в runtime
• Дверной глазок с изображением
• ИК-приемник
• Большая клавиатура на стене, кнопок которой нужно касаться ладонью
• RFID-датчики
• Матричные клавиатуры
• Светодиодное табло с текстом
• Шаговый двигатель для стрелочных механических советских часов

Всё это плавно раскидано по 6 комнатам.

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

В качестве управляющего устройства используется обычный ПК с Debian. На нем запущен демон, контролирующий весь квест. В качестве сети используется Ethernet и протокол UDP. Ethernet хорошо поддерживается как компьютерами, так и периферией (avr). UDP прост в реализации, а поэтому существуют хорошие библиотеки для МК, его поддерживающие.


Серверная квеста. Один компьютер (нижний слева) управляет всем, остальные нужны для показа видео.

Разнообразие периферии приводит к трем типам устройств, которые нужно подключить в сеть. Это Arduino Mega, Raspberry Pi и обычный компьютер с Debian. Последние два не вызывают вопросов, на первом стоит остановиться.

AVR

В качестве языка программирования выбран C++ (компилятор avr-g++), в качестве утилиты для сборки — CMake. В отличие от Arduino IDE это позволило автоматизировать процесс сборки и добиться большей гибкости. Например, можно получить доступ к таймерам и прерываниям, которые нужны для реализации квестовых задач, но по умолчанию заняты кодом Arduino.

В качестве модуля Ethernet выбран недорогой Microchip ENC28J60 (~250р). В качестве библиотеки используется EtherCard. Она обращается к arduino-style функциям, например, pinMode. Вместо того, чтобы переписывать библиотеку, мы взяли из кода Arduino реализацию тех функций, которые нужны, тем самым получив «мини-версию» ядра Arduino. CMake позволяет легко подключить «мини-ядро» к проектам.

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

Система не имела бы смысла, если бы нельзя было поменять прошивку контроллера или перезагрузить его удаленно. Приходилось бы, как и раньше, ломать стены и подключать ноутбук. Мы решили эту задачу, используя проект avr-etherboot, немного изменив его для работы с Mega 2560. Работает он следующим образом: файлы .hex с прошивками хранятся на центральном компьютере и доступны по протоколу TFTP. Avr-etherboot генерирует bootloader, который прошивается по ISP в каждый контроллер. Именно ISP, т.к. прошивка по USB-UART реализована bootloader-ом Arduino, который может уже отсутствовать. При начале загрузки контроллера запускается bootloader, подключается к сети и скачивает по TFTP прошивку (каждый контроллер скачивает свою, т.к. bootloader-ы немного разные). Далее происходит работа прошивок на каждом МК. Написанный скрипт позволяет сгенерировать bootloader для каждого МК в квесте и прошить его одной командой.

Но что делать, если в прошивке есть ошибка, и нужно ее заменить? Как перезагрузить все МК? Для этого мы используем реле (т.к. их всего в квесте около 50, используем 8-канальные), через которое проходят питания всех ардуин, кроме одной. Последняя управляет этим реле и перепрошивается по USB с центрального компьютера.


Выглядит непросто, но написанные один раз скрипты позволяют перепрошить все устройства одной командой, если это требуется.

Смешное, но важное замечание: поскольку мы пользуемся отладочной платой в «продакшне», нужно постоянно думать о надежности. Не один час потрачен на дебаг кода, когда проблема была в отвалившемся проводе. Поэтому соединение периферии с МК, ENC с МК и питание сделаны при помощи проводов и клеммников PLS и BLS. Опыт показывает, что без кримпера зажать их хорошо не всегда получается, поэтому остается один вариант — пайка. Большая часть поломок в квесте, из-за которых приходится отменять игры — не проблемы в коде или логике, а банально отвалившиеся провода.

Центральный компьютер

Итак, мы имеем периферию, которая может воспринимать действия игроков либо сама что-либо делать. Также имеем сценарий квеста. Стоит сказать, что это не просто последовательность действий: в нем возможны варианты. Например, можно сначала пройти комнату А, а потом комнату Б, а можно и наоборот. Есть еще и задачи, работающие «независимо», например, можно сколько угодно раз нажать на кнопку, после чего загорится пресловутая лампочка, причем сделать это можно в любой момент, независимо от пройденных этапов. Как это проще всего реализовать?

Будем использовать несколько процессов. Каждый процесс будет иметь полный доступ к периферии. Также процессы будут взаимодействовать между собой. В отдельные процессы вынесем независимые задачи и ожидания событий (например, введен правильный пароль в клавиатуру). Когда событие наступает, процессы будут реагировать нужным образом.

Основной сценарий — отдельный процесс. Он ожидает событий прохождения каждой из комнат, а также дает команды периферии на выполнение действий.

Реализовано всё это на C++ и стандартных библиотеках (unistd.h, sys/*). Взаимодействие между процессами выполнено при помощи неименованных pipe-ов. Для того, чтобы из одного UDP-сокета периферии могли читать несколько процессов, используется «разветвляющие» pipe, по количеству слушающих процессов. Пакет, полученный от определенного устройства, пересылается во все эти pipe, слушающий процесс читает уже из своего pipe.

Дополнительно прикручен TCP-сервер, который позволяет управлять квестом, создавая события и показывая лог. Есть возможность общаться с периферией напрямую через него, что очень полезно при отладке, т.к. не нужно «гасить» quest-daemon, чтобы освободить порт и получить доступ к периферии. TCP-сервер дает возможность создать веб-интерфейс к квесту, позволяющий контролировать квест с планшета.


Схема демона в контексте остальных компонентов

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

1. Процесс 1, сценарий ждет события «запустить квест» (блокирующий вызов)
2. Оператор нажимает на кнопку в веб-интерфейсе. По цепочке это создает соответствующее событие, сценарий продолжает работу
3. Сценарий запускает процесс 2, «задача 1», ждет события «задача 1 пройдена»
4. Задача 1 запускает процесс 3, «поиск правильного пароля», ждет соответствующего события от него
5. Игрок вводит пароль. Каждое нажатие обрабатывается процессом 3. Когда во входной последовательности встретился правильный пароль, процесс 3 генерирует событие «задача 1. введен правильный пароль»
6. Блокирующий вызов в процессе 2 завершается, процесс 2 отдает команду «зажечь лампочку». Она передается периферии. Процесс 2 генерирует событие «задача 1 пройдена»
7. Блокирующий вызов в процессе 1 завершается, процесс 1 отдает команду «открыть входную дверь». Квест пройден

Иллюстрация к примеру выше

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

Веб-интерфейс квеста
 


Для удобства дебага все события записываются в системный журнал:


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

Задачи

Когда архитектура придумана, остается только подключить периферию и протестировать задачи. Ниже процесс разработки и результаты:


Видео с разработки:


Итого устройств:

• 6 x PC
• 2 x Raspberry Pi
• 5 x Arduino Mega + ENC28J60
• 40 реле

Общие замечания:

Заключение

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

Все поломки, произошедшие с момента запуска, происходят из-за «железных» проблем (сдох компьютер, оторвался провод, ...). При помощи удаленного управления за короткое время удается определить, что же именно сломалось. Большую часть можно починить удаленно, сообщая операторам, что делать. Изменения квеста от заказчика также выполняются «из дома».

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



Если кому-то понадобится код, я создам публичный репозиторий. Основной закрыт, т.к. в нем содержится сценарий и другие секретные штуки.

Спасибо за внимание!