Пользовательский интерфейс
Очень важной частью разработки CTF было создание командного пользовательского интерфейса (UI).С его помощью игроки должны осуществлять все действия, связанные с игровой механикой.
Мы знали по личному опыту, что общее впечатление от CTF во многом зависит от качества пользовательского интерфейса, поэтому очень серьёзно подошли к дизайну и удобству использования.
Пользовательский интерфейс представлял собой веб-приложение, которое взаимодействовало с системой жюри через MongoDB и AMQP-RPC. За основу мы выбрали комбинацию Pyramid+Nginx. Система уведомлений была реализована во Flask. Требования к пользовательскому интерфейсу были следующими:
- Интерактивность .
В среде CTF очень важно оперативно получать уведомления об игровых событиях: изменении состояния сервисов, появлении новых заданий, операциях с ресурсами и т. д. Мы постарались сделать все, чтобы система держала пользователей в курсе событий.
свидание с событиями.
- Производительность .
Как уже говорилось, отзывчивость интерфейса может решить исход игры.
В большинстве случаев приложение обрабатывает запросы сразу, не дёргая лишний раз систему присяжных и не делая их отложенными.
Например, решения проверялись без обращения к системе присяжных.
- Отказоустойчивость .
Архитектура пользовательского интерфейса позволила развернуть систему на нескольких хостах прозрачно для пользователей.
Однако в игре это было не нужно, так как у нас был достаточно мощный сервер.
- Безопасность .
Как и во всех остальных компонентах, нужно было быть готовым к атакам команд. Пользовательский интерфейс был максимально изолирован от других компонентов системы.
Например, доступ к базе данных был только для чтения, а связь с Системой жюри осуществлялась через AMQP.
Удобство использования
Важнейшая задача пользовательского интерфейса — предоставить участникам интуитивно понятный интерфейс.Мы не питали несбыточных надежд и понимали, что для участников CTF любая легенда и антураж отходят на второй план.
Самое главное — решать проблемы, а пользовательский интерфейс не должен отвлекать игроков.
Юзабилити было одним из главных приоритетов, и в связи с этим мы пять раз меняли дизайн.
Первые версии пользовательского интерфейса были выполнены в светлых тонах, с плоскими минималистичными элементами.
Впоследствии мы раскрасили интерфейс для лучшего восприятия, а также изменили фон на темный, чтобы поддержать атмосферу компьютерных игр (как оказалось, дизайн почти всех игр выполнен на темном фоне).
Иллюстрации монстров из комикса очень хорошо вписались в дизайн страницы квеста, но кроме этого в интерфейсе больше ничего, связанного с легендой, не было.
Текущие игровые события отображались в виде всплывающих сообщений в стиле «ВКонтакте».
Кроме того, можно было просмотреть журнал событий с самого начала игры.
Ээволюция интерфейса табло 
Финальная версия страницы задач
Визуализатор
С самых первых дней разработки CTF было решено, что визуализация игрового процесса необходима.
Прежде всего, это нужно для того, чтобы привлечь как можно больше сторонних зрителей и интегрировать хакерские соревнования в контекст форума PHDays III.
Концепция
Во-первых, нужно было понять, какие события следует показывать зрителям, чтобы им было интересно наблюдать за происходящим, и в то же время, чтобы процесс был максимально информативным.Мероприятия были разделены на две категории:
- Атака на сервис.
Может происходить в очень большом количестве (до 138 240 событий за игру).
- Другие события.
Встречаются довольно редко - решение задания (до 250 за игру), убийство босса (4 за игру), получение достижения (до 391 за игру)
Редкие события необходимо сделать максимально заметными, чтобы они не терялись на фоне частых.
Проанализировав все события, сравнив их с придуманной легендой и игровой механикой, мы разработали рабочую концепцию визуализатора:
- События происходят на карте мира Д’Эррорим (вид сверху).
- У каждой команды есть свой замок – место, где живут герои команды.
- Рядом с замком есть пять шахт, где команды добывают ресурсы.
- У каждой команды есть свое летающее существо (дракон), которое предназначено для визуализации всех активных событий.
- В центре карты расположены 25 домов, обозначающих задания.
- Помимо хижин, здесь есть еще три обычных золотых прииска.
Карта Д'Эрроррима из визуализатора Визуализация событий:
- Атака на сервис .
Дракон циклически облетает все мины, которые команда атаковала в прошлом раунде.
Подлетев к шахте, он начинает атаковать мину, сделав над ней несколько кругов.
Таким образом, все драконы непрерывно летают по карте, отображая атаки, совершенные в предыдущем раунде.
- Решение задачи .
Дракон прерывает свой маршрут и летит атаковать дом, соответствующий решенной задаче.
При этом все, кроме дракона и дома, затемняется, тем самым подчеркивая это важное событие.
- Убийство Босса .
Когда жизнь босса истекла и стало ясно, какие команды смогли его победить, их драконы прерывают свой путь и летят в атаку.
Через некоторое время босса разрывают на кровавые куски, а драконы разбегаются кто куда.
- Получение достижения .
Сверху экрана ставится штамп с названием достижения и командой, получившей его.
Нам еще нужно много красивой анимированной графики, нужен режим динамического просмотра карт. Камера должна периодически менять свое положение, плавно приближаться к местам происходящих событий и двигаться назад, «следить» за действиями драконов и показывать всю карту.
В общем, камера должна быть «живой», предсказывать интересующие зрителя моменты и наводить на них.
Расширение границ
После того как первая концепция была готова и пришло время приступать к созданию приложения, нас осенила идея: а что, если сделать мобильную и онлайн-версии визуализатора? На сегодняшний день это очень перспективное направление, которое поможет привлечь и заинтересовать еще больше зрителей! Как было бы здорово и необычно, если бы за прогрессом CTF можно было наблюдать из любой точки планеты, где есть доступ к Интернету – такого еще никогда не было! Идея была встречена с большим энтузиазмом.Однако это в свою очередь не только усложнило архитектуру проекта, но и добавило необходимость интерактивного взаимодействия с пользователем.
Было решено создать ручной режим управления камерой, а именно прокрутку и масштабирование с помощью сенсорного интерфейса.
Помимо просмотра карты пользователю необходимо иметь возможность просмотра общего рейтинга и информации о каждой команде, а также возможность отслеживать дракона конкретной команды.
Интерактивный интерфейс визуализатора 
Рейтинг команд в визуализаторе 
Профиль команды в визуализаторе
Архитектура
Когда все требования к системе продуманы, пора приступать к разработке архитектуры проекта.Сразу было понятно, что приложение распространяется и состоит из нескольких ссылок:
- услуга , получение событий от системы жюри;
- веб приложение , возвращая игровые события и состояние игры клиентам;
- клиент , визуализация игровых событий;
Схематическое изображение архитектуры визуализатора К моменту начала проектирования визуализатора работа над системой жюри и пользовательским интерфейсом игрока шла полным ходом, а в качестве каналов связи уже были выбраны очередь сообщений AMQP для передачи игровых событий и база данных MongoDB для хранения состояния системы.
Передавать сообщения между клиентом и сервером было решено в формате JSON, так как это очень удобно и достаточно компактно.
Первое звено визуализатора — сервис.
При поступлении события в очередь AMQP сервис должен преобразовать его из формата системы жюри в формат клиентского приложения, а также обновить состояние игры.
Вся полученная информация сохраняется в базе данных MS SQL. Вторая ссылка — веб-приложение, которое принимает запросы клиентов и возвращает события и состояние системы из базы данных в формате JSON. Последняя ссылка — клиент визуализатора, приложение, которое запрашивает список событий и состояний с сервера и отображает полученные данные в соответствии с концепцией, изложенной выше.
Выбор инструментов разработки
Серверная часть визуализатора (как сервис, так и веб-приложение) написана для платформы .NET на C#.
Инструменты были выбраны во многом из-за предпочтений разработчика, который занимался этой задачей.
C# — достаточно мощный и в то же время простой язык, хорошо подходящий для реализации подобных приложений, поэтому разработка шла быстро и без проблем.
Выбор СУБД MS SQL Server был также обусловлен простотой взаимодействия с инструментами C#.
Клиентская часть по сути представляет собой обычную компьютерную игру, но без возможности управления игроком, поэтому исходя из требований необходимо было найти кроссплатформенный игровой движок, работающий на Android, iOS и HTML5. Мы рассмотрели возможности различных двигателей, но ни один из них не смог полностью удовлетворить наши потребности.
Варианты написания собственного кода для каждой платформы при использовании одного API были сразу отвергнуты, так как не было времени писать три разных проекта.
Также выяснилось, что игры, написанные на «чистом» HTML5, довольно требовательны к производительности, и запустить их на старых устройствах нет возможности.
Мы уже почти отчаялись найти что-то более-менее подходящее, когда нам на глаза попалась программа Game Maker: Studio. Game Maker — это среда, использующая собственный C-подобный язык программирования GML, созданный специально для игрового дизайна, со встроенным редактором карт, редактором изображений и многими другими полезными функциями.
Более того, GMS поставляется с целым набором компиляторов в машинный код для различных платформ, включая Windows, OS X, Linux (Ubuntu), HTML5 (JavaScript), iOS, Android версии 2.2 и выше, Windows Phone. Также нас порадовала производительность по сравнению с другими движками (25-30 кадров в секунду на HTC Desire с Android 2.3.5).
Единственный минус - продукт не бесплатный, но с покупкой лицензии проблем не возникло.
В результате все сошлись во мнении, что Game Maker идеально подходит для наших задач, и начался этап разработки.
Разработка клиента визуализатора в Game Maker: Studio
Разработка
Разработка началась за полтора месяца до начала PHDays III. Но учитывая, что приложение еще нужно было пройти валидацию в App Store и Google Play, срок поставки составляет ровно месяц! Работа шла день и ночь, в жару и в холод. Все 30 дней над визуализатором не покладая рук работали два человека.Поскольку серверная часть в некотором роде является всего лишь транслятором сообщений, сложностей с ней практически не возникло.
Однако мы ожидали большого количества запросов от клиентов, поэтому реализовали кеширование и минимизировали объем отправляемого трафика.
С клиентом дела обстояли иначе, так как там использовался необычный язык программирования со своей спецификой, со своим API и своими законами.
Самой необычной частью разработки клиента стало создание сенсорного интерфейса с прокруткой и масштабированием.
По умолчанию Game Maker предоставляет примитивы для работы с мультитач-интерфейсом, но прокрутку и масштабирование карты пришлось разрабатывать с нуля.
Существует понятие «видимая область уровня» с различными параметрами, такими как координаты, размеры области, угол поворота и т. д. Меняя перечисленные параметры в зависимости от положения курсора, были достигнуты очень хорошие результаты.
Также необходимо было учесть, что разрешение и соотношение сторон на разных устройствах могут сильно различаться, поэтому при инициализации приложения рассчитываются разные поправочные коэффициенты для корректной работы и отображения всех частей интерфейса.
Другая проблема заключалась в том, что эффекты отображались неправильно в версии приложения HTML5. Оказалось, что встроенная в Game Maker система частиц при создании игр для HTML5 в принципе не позволяет использовать аддитивное смешивание и не может раскрашивать частицы в разные цвета, если браузер не поддерживает WebGL. В связи с этим нам пришлось создать собственную систему частиц, использующую функции работы со спрайтами.
Поскольку необходимо было обеспечить быструю работу приложения на старых мобильных устройствах, система частиц оказалась достаточно быстрой и прекрасно функционировала на всех платформах, включая HTML5. Окончательные изменения в клиентской части визуализатора были внесены за день до завершения проекта.
Однако все получилось именно так, как планировалось с самого начала! Помимо кропотливой работы и сумасшедшего энтузиазма разработчиков, уложиться в сжатые сроки помог Game Maker, который (несмотря на свои особенности) имеет понятный и логичный интерфейс, хорошую документацию и множество функций, существенно облегчающих разработку игр.
Страница визуализатора в магазине Google Play
На протяжении всего процесса разработки мы не забывали о тестировании.
На начальных этапах мы отлаживали каждую часть системы отдельно, затем проводили тестовые игры (всего их выполнено пять).
Финальное тестирование проводилось накануне игры на площадке форума во Всемирном торговом центре.
Заключение
Перед началом соревнований неприятный технический сбой добавил всем нам немало седых волос: электросеть не выдержала нагрузки, когда к ней подключились все команды.К счастью, эту проблему быстро устранили с помощью нового электрощита, и с тех пор все пошло вполне гладко.
В результате победителем PHDays CTF стала голландская команда Eindbazen, второе место заняли американцы из PPP, а третье место заняли наши соотечественники из команды More Smoked Leet Chicken. Вот и все.
Мы надеемся, что вам понравилось изучать процесс создания игры.
Будем рады ответить на вопросы в комментариях.
Спасибо за внимание! Авторы: slim_d0g Блекзерт муодов ки11обайт Асперка P.S. Подробное описание процесса подготовки игры (включая тестирование) и полная легенда соревнований.
доступный на официальном сайте PHDays. Теги: #PHDays #PHDays #PHDays #PHDays #ctf #захват флага #разработка игр #информационная безопасность #Разработка игр #ctf
-
Три Истории И Один Вопрос
19 Oct, 24 -
12 Советов По Созданию Макетов В Браузере
19 Oct, 24 -
Хипстерский Бутстрап. Помните Тысячелетие!
19 Oct, 24
