Идем в музей! Как мы добавили интерактива в работу музея
Друзья, привет! На связи Антон, CEO Kobak Lab.
Статья – длинная, но и проект был непростой, интересный, и зацепил настолько, что решил накидать статью, пока летел.
Для кого она: для тех, кто разрабатывает приложения для арт-гидов, экскурсий, спектаклей. Итак, поехали!
Среди 200 музеев родного Петербурга есть Музей истории религии.
Мне довелось познакомиться с сокураторами спектакля "Кто раскачивает деревья?" Женей Львовой и Наташей Кондратюк, которые пригласили нас разработать приложение для реализации необычных творческих задач в музее.
Подготовка проекта
Мы сразу решили, что решение - в оригинальности.
Задача, которую мы решали – создать иммерсивный аудио спектакль в пространстве постоянной экспозиции музея для двух действующих лиц: взрослого и ребенка. Техническая задача - запускать определенный синхронный звукоряд при перемещении по музею, в определенные моменты способствуя игровому взаимодействию участников.
Забегая вперед, расскажу, что спектакль называется «Кто раскачивает деревья?». Это аудио экскурсия-спектакль для ребенка и взрослого (которого хочется обнять!), рассчитанный на двоих. Нужны две пары наушников, два телефона и компас. Все выдается в Музее, ничего приносить не нужно.
Сам проект прямо со старта оказался глубоко эмоциональным. Мы не просто кодили и собирали, но как будто бы проживали историю героев спектакля.
Задача казалась несложной. Мы быстро перешли к прототипам, и наверное одной из особенностей проекта стал гибкий подход к разработке, из-за чего родилось множество параллельных веток продукта, каждая по-своему интересная. Самым сложным оказалось выбрать варианты сценариев для релиза, а не сама разработка
Чтобы спектакль максимально вовлекал зрителей, мы привлекли даже профессиональных актеров озвучки. Кстати, не думайте, что это напрасная трата денег! Просто представьте, если бы классные мультфильмы озвучил тоскливый монотонный голос – вся магия бы сразу пропала.
Техническая реализация
В качестве фреймворка использовался Unity. Да, впоследствии это создавало некоторые трудности, но так сложилось исторически. Смартфоны для посетителей – простые устройства на Android, которые выдавались музеем.
Для локации участников спектакля в залах музея использовались Bluetooth маячки Minew E2 Max Beacon, работающие по протоколу iBeacon. Они устанавливались в местах интереса, к которым подходили пользователи.
Маяки с установленной периодичностью транслировали пакеты данных. В каждом пакете находился идентификатор маяка и значение силы сигнала на расстоянии 1 метр до приемника.
Как только телефон с приложением оказывались рядом с определенным маячком, приложение реагировало, например запускало соответствующее аудио сопровождение, и тем самым сюжет двигался дальше.
И так от маячка к маячку посетители проходят весь спектакля, попутно выполняя простые задания.
Мы с сотрудниками музея искали такие точки, где установка будет незаметной, а передача сигнала - стабильной.
WiFi был бы удобным решением для сопряжения двух телефонов, но к сожалению, покрытие сети в музее было неравномерным.
Подождите, а что про спектакль?
Позволю здесь остановиться еще подробнее на самом спектакле – это поможет понять концепцию разработки.
Нам крайне важно было не отвлекать посетителя от самого Музея, а лишь дать функциональное дополнение, улучшающее опыт. Все же помнят, как в музее ты перестаешь смотреть на картину, а читаешь описание на телефоне?
И зачем тогда в музей было идти...
Идея спектакля родилась в лаборатории «Театр + музей: опыты коммуникации» Центра социальных инноваций «Музейный опыт» в 2020 году. Основой стали детские философские вопросы, которые создатели аудиоэкскурсии бережно собирали на протяжении года. «Мама, а почему я не родилась кошечкой?», «А когда мысли думаешь и забываешь, они все равно остаются в голове?», «А у смерти есть смерть?» – многие детские вопросы остаются с нами на всю жизнь, поэтому так здорово искать ответы вместе с близким взрослым.
Спектакль должен был дать совместный опыт взаимодействия с музейной коллекцией и дать основу для соприкосновения со сложным.
С одной стороны – это приключение. С другой – это погружение в свой собственный мир вместе с близким человеком.
В 2021 году проект “Кто раскачивает деревья?” стал победителем конкурса «Музей 4.0» программы «Музей без границ» Благотворительного Фонда Владимира Потанина. Тогда мы стали искать разработчиков, которые помогут оживить историю.
Для технической реализации важным было именно прослушивание треков в определенном порядке с привязкой к триггерам и условиям. И вот почему: треки были не только развитием приключения, но и создавали атмосферу полного погружения.
Звуковая драматургия - важная часть аудиоспектакля. В поисках вдохновения мы отправилась в штольни горного парка “Рускеала”.
Наши музыканты включились в режим импровизации: играли на японском кото и флейтах, целлофановых пакетах и колокольчиках, дудели в курительную трубку и морскую раковину, а в ответ нам отвечал хор странных и завораживающих звуков… Именно в такой мир мы стремимся перенести главных действующих лиц игрового аудио-путешествия в пространстве Музея истории религии.
Но вернемся к приложению!
Для сопряжения телефонов рассматривались варианты с подключением по Bluetooth или режиму Wi-Fi Direct. Bluetooth кажется простым и удобным решением, но были опасения, что если синхронизация телефонов и считывание меток будет одновременно происходить по Bluetooth, то качество приема сигнала от маячков пострадает. В тестах так и получилось.
Использование варианта с Wi-Fi Direct подразумевало применение одного телефона на частоте и по протоколам Wi-Fi без роутера. Но это сложное решение привело бы нас к масштабному переписыванию кода и срыву сроков.
Финальный решением стал протокол peer-to-peer: один телефон раздает Wi-Fi, т.е. становится точкой доступа, а второй просто подключается к ней.
Протокол соединения
Финальное решение мы регулярно тестировали в музее и обнаружили, что один из телефонов не всегда считывал данные. Происходило это непредсказуемо: телефон мог на 10-30 секунд "зависнуть".
Для сюжета, где посетители ходят от экспоната к экспонату в поисках ответа, это было неприемлемо.
Решение мы нашли следующее: вместо того, чтобы считывать силу сигнала с двух телефонов, мы стали считывать один телефон, который находится в моменте ближе всего к маячку.
Дальнейшие проверки в музее и тестовые прогоны показали, что эта схема достаточно надежна.
Сюжетные повороты разработки
Только мы все продумали, как появились новые идеи. Кстати, в таких проектах сложно быть в канве разработки - т.к. сам становишься творческой личностью, и хочется сделать иначе, хотя еще не сделал то, что согласовал.
Сюжет осторожно затрагивает тему разлуки. В наушниках у взрослого и ребенка звучат разные треки-задания и участники должны разойтись по разным маршрутам.
Конечно, чтобы потом встретиться вновь!
Проблема состояла в том, что если на одном устройстве трек не включится, то эпизод терял всю суть.
Рассудили так: по сюжету ребенок уходит от взрослого и ищет путь по музею самостоятельно.
Условием для запуска следующего сюжетного хода должна стать встреча со взрослым у определенного маячка.
Если эта встреча происходит в другом зале (ребенок потерялся или они решили пойти вместе), то трек не запустится, пока они вместе не дойдут до нужного маяка.
Оживить историю: триггеры и условия
Для полного включения в процесс нужны были способы, которые как-бы “позовут” посетителей включиться в сюжет. Мы использовали:
Гироскоп: фиксирует перемещения телефона в пространстве. Это функция отлично сработала когда нужно подтвердить прием задания от героя спектакля.
Вибрация: Unity предоставляет простой инструмент чтобы запустить вибрацию. Для перехода далее срабатывает триггер - вибрация на 500 мс.
Фонарик: включение и выключение с кнопки в приложении.
У нас есть текущее состояние и условия перехода: намеренные, ожидаемые от пользователя движения являются триггерами для переключения действия.
Приложение знает в какой трек "проваливаться" дальше. К примеру, пользователь потряс телефон 10 секунд и тогда ему “звонит” персонаж спектакля. Или телефон трясли только 5 секунд и тогда он слышит призыв продолжать действия.
Условия и триггеры могут быть:
- Условие нахождения у маяка;
- Условия нажатия кнопки в приложении (прием звонка, например);
- Условия активации слайдера;
- Завершение трека;
- Нажатие на кнопку в приложении (доступна только для major);
- Нахождение старшего героя у маяка. И наоборот: какой трек звучит если старший герой долго не находит маяк;
- Старший и младший герои должны потрясти телефон определенное время. Сюжет предусматривает, какой трек будет звучать при успешном выполнении условия, а какой в обратном случае;
- Таймер для установки времени выполнения задания. Таймер включается после трека и автоматически выключается. После идет трек, который зависит от того, нашли ли пользователи нужный экспонат (т.е. маячок) или еще в поисках;
- Звуковые данные от пользователя. Так мы корректно называем этап “подуть в телефон”. Есть такой триггер и он очень забавный, честно!
Разветвления сюжета
В какой-то момент авторы пришли к идее о разветвлении сюжета в одном из залов. Мы нашаманили разработали такую схему:
- При приближении к экспонату маячок считывает сигнал у старшего и у младшего участника;
- Для каждого выбранного экспоната будет транслироваться свой трек. Т.е. один экспонат – один маячок – один трек. При удалении от маячка трек медленно затихает;
- В зале экспонаты расположены близко, поэтому мы откалибровали метки таким образом, чтобы они не пересекались;
- А если маячки все же не сработали, мы спроектировали сюжетное ответвление (следующий трек), которое двигает сюжет дальше без ущерба для повествования.
При выполнении условий меняется не только трек, но происходит экранный переход в приложении. Также у старшего участника есть возможность получить помощь по заданию.
В итоге, приложение подстраивается под линейный или нелинейный сюжет с помощью системы маяков, триггеров и условий.
Как выстроить процесс в таком проекте?
Самое сложное - это совместить работу творческих людей и разработчиков. Очевидно, что бэкграунд у сценариста и технаря сильно отличаются.
В проекте работал технический директор, который был связующим звеном между разработчиком и создателями спектакля. Он занимался переводом с технического на человеческий и наоборот, подбирал технологии и оборудование.
Крайне важно найти общий язык между ПМ проекта с двух сторон!
Отправной точкой работы стали блок-схемы: мы брали одну задачу и каждый схематично показывал этапы ее реализации. Получилось 2 разных схемы - одна со стороны разработчика, другая со стороны создателей спектакля.
Далее мы сводили их вместе, совмещая или удаляя лишнее. Каждая задача в проекте была решена именно таким способом. Это экономило время и у нас всегда были зафиксированы визуализируемые и согласованные этапы проекта.
Это рабочий подход в условиях, когда у вас нет жесткого ТЗ и вы работаете с творческой группой, где часто меняются запросы и корректируется концепция проекта.
Чтобы уложиться в сроки нам потребовалось установить экспериментальный и финальный периоды.
В экспериментальном периоде мы пробовали, удаляли и внедряли фичи, подстраивались под новые сюжетные линии, тестировали…
В финальном периоде изменений не было. Этот этап был четко обозначен, мы все понимали сроки и наши возможности, поэтому с определенного момента мы полностью сосредоточились на технической стороне дела.
Что дал такой подход? Не уйти в бесконечную доработку. Сначала на первый план вышла техническая реализация творческой концепции. На втором этапе первичным стало приложение: его обкатка, стабильность. Мы совместно составили список приоритетов и системно двигались только по нему.
Для каждой сцены разработчик предлагал способы реализации, условия, эффекты. Чтобы проверить как это впишется в концепцию мы делали демо, показывали работу новый фичи. Ее могли забраковать, могли добавить в спектакль. Это большая нагрузка на разработчика в плане непрерывной подготовки демо. Прибавьте к этому постоянные изменения в самом спектакле и получается коктейль не для слабонервных.
Совет не для всех лишь
Совет для разработчиков чего-либо для музеев и выставок: не стоит привязывать сюжет к цветам или объектам, которые могут измениться – фону, временным экспозициям, занавесям, указателям и т.д.
Задействовать следует только те экспонаты, которые не планируются для реставрации или перемещения в другие залы.
Это важно для сохранения сюжетной линии и триггеров. При этом, добавлять новые треки можно, но все зависит от возможности менять сценарий.
Тестирование
Тестирование было двух типов:
- Техническое: многократный прогон каждого перемещения в музее и движений сюжета, моделирование нестандартных ситуаций, проблем со связью. Мы приезжали в музей >30 раз, чтобы проверить и настроить работу техники и приложения;
- Творческое: работа фокус-группы из детей и взрослых, которые помогали отлавливать ошибки и вносить редакторские правки в спектакль. Группа рассказывала о том, насколько было комфортно, были ли технические сложности, удобно ли перемещаться по маршруту и находить экспонаты. Работа фокус-групп длилась 2 месяца.
Финал
Бизнес-задачу мы решили, но параллельно создали и задел на будущее (кстати, проектируйте ВСЕ максимально гибко - это может однажды пригодиться, чтобы не изобретать заново слона). Так, в процессе работы мы получили масштабируемую State machine для создания аудиоэкскурсий, спектаклей и гидов по выставкам.
Путем нехитрого кодинга пользователь может спроектировать работу приложения с помощью блок-схем. Фреймворк уже содержит библиотеки эффектов, триггеров и условий.
Задача пользователя – установить их в нужной последовательности и оценить творческий эффект. Фиксируются состояния, которые соответствуют действиям в сюжете. Прописываются переходы между ними.
Задача разработчика – настроить работу приложения для конкретных условий заказчика (работа маяков, корректировка схем и т.д.).
Пока писал статью (прошу прощения, если не так последовательно, как настоящие асы пера!), нашел в группе Музея в VK такой отзыв.
Пишу его вместо заключения о проделанной работе!
…По залам гуляют взрослые и дети в больших наушниках, они выпрыгивают друг на друга из-за угла, обнимаются и признаются друг другу в любви…Этому трогательному хулиганству есть простое объяснение…
Узнать подробнее о проекте и музее:
Спасибо, что дочитали статью! Если появились вопросы - с радостью все прокомментирую!