Что означает приставка io в играх
IO игры — что это? Преимущества и популярные игры
На данный момент игровая индустрия переполнена различными продуктами. Тренды стремительно изменяются. Одна из констант, которая вот уже на протяжении нескольких лет не теряет своей популярности — это IO игры. Что это такое и с чем его едят? Ответ получите после прочтения текущей статьи.
IO игры. Что это?
Это относительно новый вид виртуальных развлечений, который стремительно набирает популярность по всему миру. И это вовсе не удивительно. Ведь у данной ниши есть целый ряд преимуществ, среди которых стоит выделить:
Еще одно достоинство IO-игр заключается в том, что они абсолютно бесплатные. Причем дополнительных микротранзакций также не предусмотрено. Многие из них можно найти на специальных порталах, где имеется список популярных проектов, разделение на категории и т.п.
Популярные IO игры
Начало целому классу положила игра под названием Agar.IO. Это минималистичная и невероятно веселая браузерная онлайн-игра, которая в плане геймплея напоминает змейку. Пользователь должен поглощать других пользователей, чтобы набирать очки. Прогресс отображается в списке, который расположен в правой части сайта. Игра длиться до бесконечности, что делает геймплей невероятно захватывающим.
Обскакать по популярности Agar.IO смог лишь проект под названием Slither.IO. Она держится в списке самых популярных игрушек еще с 2015 года. Суть идентична Agar.IO, однако рассматриваемый проект считается более продвинутым за счет красивой графики, интересного стилистического оформления и обилия скинов.
На этом список IO игр не заканчивается. Существует еще целый ряд подобных аналогов. К их числу можно отнести:
Постараюсь описать устройство системы максимально просто, в таком формате, в каком это было бы наиболее понятно для меня самого — на пальцах, без углублений в код.
Игровой процесс
Для начала нужно было решить, о чем будет игра. Обдумав игровую механику двух наиболее успешных представителей — Агарио и Слизарио — мы решили, что игра должна обладать следующими свойствами:
Мы посчитали, что будет оригинально, если будет расти не сила игрового существа напрямую, а количество этих существ. Вторая идея — это возможность объединять пары более слабых существ в одно более сильное. Таким образом, в начале у нас есть одно существо, которое со временем разрастается в стаю, а стая схлопывается обратно в меньшее количество более сильных существ. Пара существ первого уровня может схлопнуться в одно существо второго, пара существ второго — в одно существо третьего, и так далее. Так мы получаем экспоненциально-замедляющуюся прокачку, которую можно раскачивать почти неограниченное количество времени.
Теперь осталось выбрать художественную составляющую. Выбор стоял между стаей микроорганизмов — вирусов, бактерий, протистов, прионов, и стаей морских жителей — рыбок, крабов, медуз. После некоторых размышлений был сделан выбор в пользу рыбок. На этом закончим с художественной частью, и перейдем к технической 🙂
Клиент
Упрощенно говоря, вся движуха происходит на сервере, а клиент является лишь монитором-визуализатором этой движухи. Все что умеет делать клиент помимо пассивного визуализирования — это отправлять на сервер действия игрока (в нашем случае — координаты курсора мыши и состояния ее кнопок). Больше ничего клиент не умеет, и не должен уметь — никакая игровая логика не должна выполняться на клиенте, иначе это моментально станет возможностью для читерства. Таким образом, с программной точки зрения, клиент — это объект, который, среди прочего:
Вот примеры сообщений, и действий по их обработке со стороны клиента:
Показать рыбу с идентификатором creature_id, которая находится в позиции position, имеет вектор скорости velocity, принадлежит игроку с идентификатором owner_id, и является рыбой типа creature_type_id.
С точки зрения JavaScript это будет например вот такой объект:
Получив такое сообщение, клиент добавит рыбу в мапу рыб, и когда дело дойдет до отрисовки игровой сцены, рыба появится на экране.
Рыба с идентификатором id1 укусила рыбу с идентификатором id2.
Получив это сообщение, клиент возьмет координаты рыбы с идентификатором id2, и добавит с такими же координатами пузырь в массив пузырей, а также пятно крови в массив пятен крови. Далее отрисовка выведет их на экран.
Таким образом можно сказать, что сообщения от сервера клиенту — это в основном уведомления о том, что в поле зрения клиента что-то произошло. Что-то такое, о чем клиент должен знать, чтобы правильным и понятным образом (графически) уведомить об этом игрока. Примеры других типов сообщений — «игра окончена с таким-то счетом», «в игру вошел игрок с таким-то именем», «список топ-10 игроков», «список всех игроков и их координат» (для отображения их на карте), и так далее.
Сервер
Сервер — это приложение, внутри которого и происходит вся игра. Сервер состоит из игровых комнат. Игровая комната — это экземпляр игровой локации. Комната имеет адекватные для геймплея геометрические размеры и лимит на количество игроков в ней. Когда все игровые комнаты заполнены, сервер создает новую комнату, и игроки постепенно распределяются равномерно между занятыми и свободной комнатами. Игровые комнаты никак между собой не связаны, и работают полностью в изоляции друг от друга. На самом верхнем уровне сервер умеет принимать входящее соединение, выбирать подходящую игровую комнату, в случае необходимости — создавать новую, и отправлять игрока в выбранную комнату.
Наш сервер написан на C++, из сторонних библиотек используется Boost, сетевая часть — Boost.Asio. Разработка и тестирование — Visual Studio / Windows, рабочий сервер — GCC / Linux.
Игровая комната
Здесь происходит вся игровая логика. Комната — это объект, который, среди прочего:
Обезжиренный интерфейс игровой комнаты на псевдо-коде:
Апдейт игрового мира
Это функция, которая реализует изменения в игровом мире, произошедшие за фиксированный отрезок времени dt (в нашем случае — 0,1 секунды), я буду называть эту функцию update. В общих чертах update игровой комнаты — это вызов update для игровых объектов, то есть вызов update далее вниз по лестнице агрегации, от общего к частному. Простой пример: пусть у нас есть рыба, находящаяся в координатах position, и двигающаяся с вектором скорости velocity. Тогда ее функия update — это вычисление ее позиции через dt времени:
Помимо перемещения, рыба может за это dt принять решение отправиться в какое-то другое место, и тогда, помимо обновления своих координат, в результате update может измениться ее вектор скорости velocity. На псевдо-коде update комнаты выглядит следующим образом:
Разбиение игрового пространства
В ряде алгоритмов, реализующих логику игры, нужно уметь перебирать объекты, ближайшие к данному. Например — показать пользователю всех рыб в поле его зрения, или проверить, не собирается ли данная рыба укусить кого-то из своего окружения. Если мы будем перебирать пары объектов по принципу «каждый с каждым», то мы получим квадратичную сложность, а это нам не нужно, ни для CPU, ни для трафика.
Для того, чтобы избавиться от квадратичной сложности, у нас используется следующий способ: пространство разбивается на клеточки, и для каждой клеточки хранится список объектов, которые находятся на данном участке игрового пространства. Доступ к списку клеточки по ее координатам имеет константную сложность.
Если нас интересует список объектов, ближайших к данному, мы запрашиваем списки клеточки, в которой находится данный объект, а также списки объектов из соседних клеточек. Итого 9 клеточек.
Разбиение на клеточки делается в два независимых дублирующих слоя — клеточки маленького размера для проверки ближних взаимодействий типа столкновений, укусов, поеданий, и клеточки большого размера для разрешения вопросов видимости — попадании объектов в поле зрения игрока.
Таким образом, сложность алгоритмов остается квадратичной, но в квадрат возводится уже не общее количество игровых объектов в комнате, а только их количество в поле видимости алгоритма.
Протокол
Отдельный вопрос — протокол взаимодействия сервера и клиентов. Под протоколом я подразумеваю описание набора и структуры сообщений, которыми будут обмениваться сервер и клиенты, их сериализацию при отправке, и десериализацию и диспетчеризацию при получении. Я использовал свое собственное упрощенное велосипедное решение — кодогенератор из JSON-описателя пакетов (так уж получилось). Если вам нужно готовое серьезное решение, а не велосипед, то есть ru.wikipedia.org/wiki/Protocol_Buffers, который тоже является кодогенератором.
Почему кодогенерация?
Очереди сообщений
Для отправки сообщений комнате используется multiple producer single consumer очередь. Для отправки сообщений клиентам — single producer single consumer. Оба типа очередей — самописно-велосипедные. Вероятно, можно было воспользоваться Boost.Lockfree, но, опять же, так уж получилось. Для (де-)сериализации и диспетчеризации сообщений, путешествующих внутри сервера, используется тот же кодогенерированный механизм, что и для передачи сообщений по сети.
Я постарался описать общую структуру игры и некоторые ее отдельно взятые, важные на мой взгляд моменты, чтобы у вас сложилась полная картина того, как устроена вся система целиком. Надеюсь, у меня это получилось 🙂
Советы
Вместе с клиентом и сервером сразу же сделайте ботов. Причем боты должны ходить на сервер по сети, по тому же протоколу, что и клиенты, и «видеть» ту же информацию, что и реальные игроки. Это существенно облегчает отладку, а также позволяет оценить потребляемые ресурсы в условиях, приближенных к боевым. Сколько всего игроков онлайн потянет сервер? Когда мы упремся в CPU или ширину сетевого канала? На эти и некоторые другие вопросы вам помогут ответить боты, тем самым избавив вас от неприятных сюрпризов после релиза. Кроме того, боты позволят сделать игру не слишком скучной, пока в ней мало живых игроков.
Сетевой трафик
Так вот, минимизация сетевого трафика. Обычно у хостинг-провайдеров трафик либо платный по счетчику, либо предоплаченный пакет с возможностью докупки, либо безлимитный, но со звездочкой-сноской, по которой находится оговорка, что на самом деле не такой уж он и безлимитный — при исчерпании определенного объема вас будут ждать карательные меры в виде, например, урезания ширины канала, или же придется таки платить сверху. Поэтому — тщательно продумайте ваш протокол и экономьте каждый байт! У нас 10000 живых игроков, отыгравших за сутки, генерировали за эти сутки порядка 200 гигабайт игрового трафика. Наверно это может показаться не так уж много, но не забывайте, что объем потребляемого трафика будет расти вместе с вашей аудиторией. Несколько сэкономленных байт в отдельно взятом пакете могут сэкономить сотни мегабайт или даже гигабайты трафика в сутки.
Ведите статистику трафика с раскладкой по типу игровых пакетов. Скорее всего вы увидите, что несмотря на то, что у вас несколько десятков типов игровых пакетов, основная часть трафика приходится на несколько из них — им-то и следует уделить особое внимание.
HTTPS
Если вы захотите сделать вашу игру в том числе iframe-игрой ВКонтакте, то придется принудительно переехать на HTTPS, поскольку раз сам vk.com работает через HTTPS, то и от iframe внутри него будет требоваться тот же протокол. А сайт, работающий на HTTPS, может работать только с SSL-вебсокетами.
Список технологий
Результат
Наша игра все еще находится в бете, но посмотреть на результат можно уже сейчас: oceanar.io (пока что работает только для десктопа, мобильные и планшетные версии на очереди).
Спасибо за внимание. В комментариях отвечу на ваши вопросы.
Особенности протокола в IO-играх
Допустим, вы хотите создать IO-игру. Что-то похожее на agar.io, slither.io и тысячи их.
Такое название закрепилось за браузерными, клиент-серверными многопользовательскими играми в реальном времени.
Механика таких игр обычно относительно проста и интерес достигается за счет эпических битв между большим количеством реальных игроков.
Родоначальником жанра является agar.io
Многие знают, что в таких играх используется websocket. И ничего сложного нет в том, чтобы создать свой протокол над ним. Я так думал, когда примерно год назад мы начинали проект космического шутера в этом стиле.
Сейчас я так не думаю.
В чем проблема
Основная проблема, которую приходится решать всем разработчикам многопользовательских игр — достижение «одновременности» происходящего.
Наивный подход: а давайте я буду передвигать своего героя, отсылать эти передвижения на сервер, а сервер станет рассылать их моим соперникам — не работает. Если поступить так, то ваш герой будет жить в реальном времени, а его соперники — в прошлом. Их движения будут отставать примерно на два пинга до сервера. Скажем, если пинг 100мс, то вы увидите где были соперники 200мс назад. Соответственно, играть будет невозможно.
Постановка задачи
Есть двухмерные комнаты в которых летают, следуя за указателем мыши, космические корабли.
Нужно создать протокол так, чтобы:
Итоговый результат — очень простой.
Но попробуйте, для чистоты эксперимента придумать свой вариант до прочтения статьи, чтобы при написании комментариев избежать эффекта знания задним числом.
Первое решение
Пусть каждый клиент при отрисовке каждого кадра посылает на сервер положение курсора мыши.
А сервер, получив его, немедленно считает текущие координаты корабля и рассылает их всем клиентам (включая и того, кто передал координаты мыши).
Все просто. Одновременность здесь достигается.
И это даже работает, пока у нас сервер стоит локально, а клиентов совсем немного.
В условиях приближенных к реальным такой подход дал три вещи: бешеный трафик (который на порядок превосходил трафик того-же agar.io), периодические «прыжки» кораблей (вместо плавного полета) и дикие лаги, которые обычно начинались через 3-5 минут, а потом не проходили уже никогда и «лечились» только рестартом браузера.
Вторая версия протокола
Первая правка была очевидной: неправильно отсылать перемещения корабля сразу после получения управляющей команды от клиента.
Если делать так, то периодичность поступления команд клиентам от сервера зависит от трех вещей:
Решение этой проблемы было простым — вместо немедленной отправки команды на клиент сделали отправку по таймеру — одна команда в 20мс.
«Прыжки» корабликов заметно уменьшились…
Третья версия
В какой-то момент, повинуясь сетевым лагам, очередной пакет приходил с большой задержкой. Не через 20мс, а через 100, например.
Соответственно, кораблик сначала тормозил, а потом резко срывался с места и «телепортировался» на несколько пикселей.
И тут возникла странноватая идея: а давайте в случае таких вот задержек все-таки будем двигать кораблик в ту же сторону, в которую он летел ранее.
Может картинка станет более плавной? Идея эта не сработала, но она оказалась шагом в сторону правильного решения.
И так, кораблик на клиенте теперь все время (то есть каждый кадр) летит со своей постоянной скоростью.
С сервера приходят команды на изменение этой скорости, а также «поправки» для координат корабля.
Результат? Вместо редких прыжков на длинные дистанции наши кораблики стали совершать серии прыжочков на короткие расстояния.
Получалось, что с точки зрения клиента корабль находится в одном месте, а с точки зрения сервера — в другом.
Присылаемые с сервера «поправки» и приводили к микропрыжкам.
Дальнейшее может служить примером, как две дебильные не совсем удачные идеи, реализованные последовательно, могут давать неожиданный результат:
А давайте будем слать поправку пореже и посмотрим, что из этого выйдет!
Ничего хорошего, конечно, не вышло — прыжки снова стали более редкими и длинными.
Но зато я обратил внимание, что управление корабликом не становится менее отзывчивым даже при кратном увеличении интервала между отсылкой поправки.
Четвертая версия
А ведь это означает, что я совершенно зря смешал две характерных величины: FPS — необходимость перемещать кораблик по экрану 60 раз в секунду, и отправку управляющего сигнала от мыши.
Управляющий сигнал можно отсылать гораздо реже, поскольку он коррелирует не с особенностями человеческого зрения, а со скоростью человеческой реакции.
А она — примерно 200-250мс!
С учетом пинга до сервера (примерно 100мс) это означало, что управляющие сигналы можно посылать примерно раз в 100-150мс, а плавность движения уже обеспечивать на клиенте.
В итоге четвертая версия протокола выглядела так:
Но самое главное — автоматически решилась проблема тяжелых лагов, наступающих через 3-5 минут и неизлечимых ничем.
(Через несколько дней мне попалась вот эта статья и стало понятно, что именно там происходило).
Теперь оставалась только одна проблема — мелкие прыжочки кораблей во время синхронизации.
Версия пятая — конечная
Если синхронизацию не делать или делать её редко, то местоположение кораблей на сервере и на клиентах оказывалось разным, что естественно было неприемлемо.
Но терпеть прыжочки, которые превращались в прямо-таки полноценные прыжки при любой сетевой задержке, мы тоже не хотели.
Первоначальная мысль выглядела так: А что если мы «размажем» синхронизацию по времени? Вот не будем сразу перемещать кораблик в нужную точку, а скажем ему переместиться туда кадров за 7-8?
— Так, но ведь это — дополнительная задержка…
— А кстати, мы ведь меняем скорость кораблика только раз в 120мс. Значит мы заранее знаем где он будет через 120мс!
— С этого места подробнее!
Так родилась простейшая (при её рассмотрении задним числом) идея: вместо синхронизации, сервер отправляет клиенту координаты корабля, на которых он должен быть через 120мс.
И весь протокол стал таким:
Даже если по какой-то причине в момент получения новой цели кораблик не достиг (или перелетел) прежнюю, это никак не скажется на плавности хода — лишь немного подкорректируется скорость.
Смотрите, как увеличивается количество игроков
Возможно, вы уже встречали игры, в названии которых фигурирует «.io». А знаете, что это значит? Все началось с игры Agar.io. Ее суть заключалась в поглощении небольших сфер, за каждой из которых скрывался реальный игрок.
Создатель Agar.io Матеус Валадарес вспоминает, что проводил часы перед микроскопом за изучением расползающихся клеток. «Я подумал: это же выглядит довольно круто. А не сделать ли из этого игру?»
За несколько месяцев Agar.io дала толчок появлению множества игр с «.io» в названии. Их создатели брали за основу идеи Валадареса. «Как и Agar.io, эти игры чаще всего весьма просты в управлении».
Следующая разработка Валадареса была в том же духе. В Diep.io неограниченное количество участников проходят уровень за уровнем, чтобы добиться звания короля. «Diep.io была создана всего за две-три недели».
Успех меняет игру — чем вы успешнее, тем уязвимее. В Agar.io (и играх, созданным по ее следам) чем сильнее вы становитесь, тем больше времени проводите в игре и тем больше игроков стремятся вас обойти.
В игре Slither.io нужно управлять змеей, вырастающей до гигантских размеров. В Hexar.io вы оказываетесь на поле, состоящем из шестигранных плит, а ваша задача — обрисовывать периметры кластеров, чтобы увеличивать свои владения.
Матеус Валадарес, создатель Agar.io
В названии игры Crash of Cars хотя и нет «.io», но выдержана она в лучших традициях подобных проектов. Подчинить себе соперника — вот, что предстоит сделать.
«Я и представить себе не мог, что в созданную небольшой командой игру в итоге будут играть миллионы», — говорит Валадарес.
Первыми ласточками, сорвавшими куш популярности были знаменитые Agar.io и Slither.io и подобные им.
Структурирую поток мыслей:
Низкий порог входа по ресурсам для разработчиков
С другой стороны, почти каждый плюс оборачивается и минусом.
Нельзя выехать просто на красивой графике, нужно поработать над геймплеем и механиками )
Монетизировать внутриигровыми покупками сложно
Из-за низкого порога входа на рынке очень много низкокачественных io игр
Если что-то забыл, добавьте жару в комментариях!
В ближайших постах буду обозревать новинки ИО игр (не забывая, конечно, и про другие HTML5\WebGL проекты), постараюсь разобраться в лучших игровых механиках и приемах монетизации.
Как эта статья относится к геймдизайну не очень понятно
В будущих постах постараюсь ближе к геймдизайну. Но про сам кодинг тут не будет.
Ирал в пару игр, типа Hole.io, но быстро понял, что никакие они не многопользовательские, а просто наебалово. Ставишь на паузу, продолжаешь с того же места. Там боты. Онлайном и не пахнет.
ну в больших хитах везде игроки живые, и не на мобилках, а в ПК брауезере
Да, тоже замечал. В мелких новых играх особенно.
так-то вроде бы они и ничего, но не для геймеров. Где-то на уровне гиперкэжа.
HTML Господин
Шо так скромно, можно было сразу «HTML Властелин»
Тоже такое себе. Лучше сразу «HTML Бог».
О, конкурент мобильному геймингу подъехал)
Игры? Круто? Не более, чем мобилки.
Так что в итоге-то?
Круто или нет?
А круто потому что на утюге запустить можно или еще по каким-то причинам?
Круто, что на утюге ее смогут запустить сотни тысяч
От поста в индустрийном разделе я ожидал несколько более глубокого анализа, ну окей, мои ожидания — мои проблемы.
Дополнил пост, спасибо.
Ну его заодно и перенесли в другой раздел.
Из всех игр больше всего зашла https://play.aidungeon.io
Вообще огонь
*meduza.io вышла из чата*
Очень интересная статья, автор молодец, желаю удачи в дальнейших статьях!)
Я ТЕБЯ УКУШУ |21/09|-|||Білий|сир||добрий|кіллер|13|24|19|8|17|17|445|0|1|0|1|1|329|19|34|0|0|9|9|0|0|1|1|87|0|0|40|0|0|179|0|0|0|41|0|63|63|22|22|67|61|58|58|0|45|14|14|32|32|0|38|0|0|0|62|16|16|0|0|1|1|0|2|2|1|6|7|11|11|1|14|1|7|7|1|20|0|9|1|1|0|0|0|2|0|0|1|0|1|1|1|1|0|0|0|0|0|2|8|1|19|0|-2|8|1|19|0|0|1|2|3|0|0|1|2|3|0|3|10|1|1|3|-3|10|1|1|-3|0|0|1|19|0|-1|-1|19|19|0|18|8|3|3|30|0|2|1|1|0|-4|18|8|11|0|6|-2|6|18|318|2|4|4|20|0|12|22|1|1|24|0|0|1|1|0|-4|4|2|2|0|0|0|1|1|0|0|0|0|11|11|0|0|0|1|1|0|1|0|-1|11|20|3|-28|18|1|1|1|1|348|0|1|0|3|3|1|0|1|1|1|1|1|1|1|1|1|1|1|1|20|14|1|1|15|2|0|0|1|1|19|1|0|4|4|1|2|-30|0|1|1|315|-4|10|0|0|0|0|0|0|0|1|1|1|0|0|0|4|0|-12|0|0|0|0|F5EAE2|9F8F86|D4AE91|8A624F|A17261|D4AE91|8A624F|A17261|D4AE91|8A624F|A17261|D4AE91|8A624F|A17261|D4AE91|8A624F|A17261|FFFFFF|513121|020202|FFFFFF|020202|020202|FFFFFF|020202|FFFFFF|191919|FFFFFF|191919|FFFFFF|C6B4A3|FFFFFF|C6B4A3|020202|020202|ECECEC|7F7EA6|020202|7F7EA6|020202|020202|020202|BBD4FF|020202|BBD4FF|FFBBDC|01ECE5|020202|BB9178|FF8383|020202|FFFFFF|ECECEC|54473C|FFFFFF|020202|020202|FFFFFF|796D68|8A6E5E|D4C6BC|B1DEB5|020202|00132C|796D68|8A6E5E|D4C6BC|020202|B8B8B8|FFFFFF|191919|020202|020202|020202|020202|020202|020202|020202|020202|FFFFFF|B8B8B8|FFFFFF|FFFFFF|B8B8B8|FFFFFF|FFFFFF|020202|020202|FFFFFF|020202|020202|FFFFFF|00232C|020202|FFFFFF|020202|191919|FFFFFF|ECECEC|AAA7CB|FFFFFF|ECECEC|AAA7CB|FFFFFF|020202|54473C|191919|020202|54473C|020202|24014F|FFFFFF|FFFFFF|00413F|020202|FFFFFF|020202|A39482|020202|333333|D4D4D4|020202|191919|FFFFFF|FFFFFF|020202|020202|FFFFFF|020202|020202|C49067|9F7554|FFFFFF|333333|020202|FFC2C2|FFFFFF|020202|FFFFFF|FF3F3F|020202|191919|020202|989898|3CFFF9|020202|989898|3CFFF9|00224F|020025|FF0BD4|00224F|020025|FF0BD4|020202|020202|020202|FFFFFF|020202|FFFFFF|020202|FFFFFF|FFFFFF|FFFFFF|020202|020202
:3|2/22/2000|20|Type profile here.|Creator|Blue|Rice|USA|Funny|Student|1|1|1|6|5|5|47|0|1|0|1|1|283|137|74|0|0|14|14|2|2|22|22|122|51|0|0|0|85|0|0|0|0|35|0|31|31|40|40|18|18|71|71|59|0|2|2|0|0|0|92|30|0|0|86|0|0|0|0|1|1|0|1|1|1|12|4|14|14|1|1|1|7|7|1|1|1|1|1|1|0|0|35|18|0|0|1|0|1|1|1|1|0|0|0|0|0|0|0|1|1|0|0|0|1|1|0|0|0|1|1|0|0|0|1|1|0|0|0|1|1|0|0|0|1|1|0|0|0|1|1|0|0|0|1|1|0|0|-4|1|1|351|0|0|1|1|0|0|-18|1|1|0|0|0|1|1|0|0|0|1|1|0|0|0|1|1|0|0|0|1|1|0|0|0|1|1|0|0|0|1|1|0|1|1|0|1|1|0|0|0|1|1|0|1|5|0|8|1|1|0|0|1|1|1|0|0|1|1|0|0|1|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|2|0|0|1|1|0|1|0|0|0|1|1|0|0|1|1|0|0|0|0|0|0|0|0|0|0|1|1|1|0|0|0|0|0|0|0|0|0|0|FFE2D4|191919|B4BFCD|93A1B1|ECF0FF|B4BFCD|93A1B1|ECF0FF|B4BFCD|93A1B1|ECF0FF|B4BFCD|93A1B1|ECF0FF|B4BFCD|93A1B1|ECF0FF|B15482|ECF0FF|ADDED9|020202|020202|ADDED9|020202|020202|8EFBFF|3A1F17|8EFBFF|3A1F17|8A624F|020202|8A624F|020202|BBD4FF|020202|E0F4FF|FFFFFF|020202|D4D4D4|8589FF|020202|FF93BC|7F7EA6|020202|8AAEFF|FF8383|191919|FFC2C2|020202|FF8383|020202|FFFFFF|989898|020202|ECECEC|DEECFF|020202|3A82FF|EBE0FF|020202|8AAEFF|0256C9|020202|8AAEFF|E0E1FF|020202|8ACEFF|57678C|020202|2E263F|FFFFFF|020202|4638FF|AAA7CB|020202|EEE9FF|AAA7CB|020202|EEE9FF|57678C|020202|24253A|57678C|020202|24253A|AAA7CB|020202|525270|AAA7CB|020202|525270|585858|020202|D4D4D4|7B7B7B|020202|EEE9FF|EEE9FF|020202|B4BFCD|EEE9FF|020202|B4BFCD|B8B8B8|020202|D4D4D4|B8B8B8|020202|D4D4D4|527085|020202|24253A|527085|020202|24253A|FFFFFF|020202|BCBBFF|D4D4D4|020202|FFFFFF|A487FF|020202|8AAEFF|FFFFFF|020202|A487FF|FFFFFF|020202|A487FF|BDE3FF|020202|E0F4FF|FF3F3F|020202|FFFFFF|FF3F3F|020202|FFFFFF|FF3F3F|020202|191919|8589FF|020202|FFFFFF|8589FF|020202|FFFFFF|AAA7CB|020202|B4BFCD|AAA7CB|020202|B4BFCD|020202|020202|020202|FFFFFF|020202|FFFFFF|020202|020202|51FF38|51FF38|020202|020202