Как IceStone от идеи конвертировать Flash в HTML5 пришла к запуску собственного издательства

Статья — адаптированная версия доклада Игоря Чавычалова «Конвертация Flash в HTML5 с IceStone. Воскрешение продукта без затрат и с полным циклом паблишинга», прочитанная на митапе по разработке HTML5-игр в офисе Mail.ru 13 марта.

Игорь Чавычалов

С чего все началось?

У нас был собственный игровой движок на C++. На нем создавались игры, которые для отображения в вебе компилировались во Flash.

Несколько лет назад ситуация изменилась. Flash начали блокировать браузеры, все заговорили о необходимости перехода на HTML5.

Мы тоже начали искать решение, которое позволило бы нам переехать на «новые рельсы». Так мы пришли к компилятору Emscripten, который позволил конвертировать наш код C++ в желанный HTML5.

Казалось бы, победа, но далеко не все проекты из нашего портфолио были написаны на C++. Хватало игр, разработанных изначально на Flash.

Что делать с ними, было не совсем ясно, ведь вариант с портированием мы сразу отмели. При этом бросать проекты, у которых до сих пор есть продажи, было жалко.

Почему мы не взялись за портирование?

У тех, кто сегодня занимается портированием с Flash, обычно два пути — Unity и HTML5.

Unity

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

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

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

Последнее особенно критично, учитывая, что более 80% всего веб-трафика идет именно с мобайла.

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

HTML5

С HTML5 во многом те же проблемы, что и с портированием на Unity. То есть вам в первую очередь потребуется новая команда и много времени, которого сегодня у владельцев Flash-проектов нет.

Напомню, в декабре 2020-го Adobe официально прекратит поддержку технологии и закроет Flash Player. Google на протяжении всего будущего года полностью отключит поддержку технологии в Chrome. Некоторые браузеры, например, Mozilla Firefox, уже отключили поддержку Flash Player.

Само портирование также дорогое. Некоторые бюджеты достигают $300-500 тысяч. King может себе это позволить, большинство разработчиков проектов на ActionScript 3 — точно нет.

И мы сейчас не говорим о больших проектах в духе Clash of Clans. Тут вообще легче повеситься, чем пытаться перевести игру на HTML5.

Опять же, как и в случае с Unity, высока вероятность возникновения ошибки. Что-то где-то не досмотрели — и в результате получили не доходный проект на HTML5, а сломанный продукт.

Какие были альтернативы полноценному портированию?

Самым очевидным нам тогда показалось найти инструмент, который может пересобрать проект Flash в HTML5. Самостоятельно писать что-то свое мы тогда были не готовы. Плюс нам казалось, что кто-то уж точно должен был что-то придумать.

В итоге мы нашли всего четыре решения, которые в теории могли отвечать нашим запросам. И ни одно из них нам не подошло, и вот почему:

Shumway

Решение Mozilla c открытым исходным кодом конвертирует все непосредственно во время проигрывания в вычислительном окружении (runtime). Это катастрофически влияет на производительность. В лучшем случае мы имели 2-3 кадра в секунду у самых примитивных игр на десктопных устройствах. Плюс сама Mozilla в 2016 году прекратила поддержку медиа-проигрывателя.

Apache Royale

Ранее назывался FlexJS. Позволяет на MXML и ActionScript писать приложения для HTML5. Проблема этого решения с открытым кодом — отсутствие полной реализации Flash API. Оно заточено под MXML и Flex-компоненты, а не под Flash-игры. У Flash API недостаточная реализация и исполняется не идентично оригиналу. Проще говоря, с помощью Apache Royale Flash-игры не сконвертируешь.

OpenFL

Здесь две основные проблемы. Первая. Предполагается, что OpenFL должна полностью отражать Flash API, а SWF, созданные в Adobe Flash, могут работать в OpenFL. Но на деле часть API у ActionScript 3 работает не так, как работает во Flash. Вторая проблема: мультиплатформенность обеспечивается исключительно через Haxe.

Связка Adobe Animate и CreateJS

Подходит исключительно для переноса анимации. Код этот набор инструментов не поддерживает.

Разобравшись, что адекватных решений нет, мы закатали рукава и сами взялись за реализацию решения, который позволил бы нам при минимуме усилий перебрасывать проекты из Flash в HTML5.

Так на свет появился IceStone.

Как шла разработка IceStone?

Мы начали делать IceStone в 2016 году. На первую версию продукта у нас ушло два года.

Весь инструментарий нам пришлось делать с нуля самим. Например, мы создали собственный Flash Player на JavaScript, а также предиктивный компилятор под стандарты браузеров, батчинг рендера и многое другое. Все вместе это позволило нам добиться втрое лучшей производительности относительно оригинала на AS3.

Сегодня наше решение на 100% поддерживает Flash API и благодаря этому позволяет относительно безболезненно переносить код в HTML5-формат, где он хорошо воспроизводится с использованием аппаратного ускорения WebGL.

Мы работаем с любыми типами исходников: FLA files, Adobe Flash Builder, FlashDevelop, IntelliJ IDEA и даже SWF.

Еще на этапе бета-версии мы подключили первого партнера. Он предоставил нам достаточно много игр, порядка 20-ти. Все они были написаны в рамках одной архитектуры. У всех был очень хороший чистенький код.

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

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

Например, мы столкнулись с тем, что у многих Flash-игр не предусмотрено изменение размеров активного окна (ресайз фрейма). Они могли воспроизводиться только в рамках одного заданного разрешения и только с одним возможным соотношением сторон.

И это было проблемой. Дело в том, что многие Flash-проекты создавались исключительно под десктопы с соотношением сторон 4 к 3. Для настольных систем широкоформатность продукта не критична. Совсем другое дело — мобильные устройства, рынок которых нельзя упускать.

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

Самое очевидное решение здесь — создание виртуального стика и пары клавиш, которые мы и реализовали.

Чего мы добились?

К настоящему моменту у нас уже отконвертировано 170 проектов. Ни на одном нет проблем с производительностью как на десктопе, так и на мобильных устройствах (на самом деле речь идет о увеличении производительности в 2-3 раза в зависимости от специфики проекта.). Причем речь здесь не только о физических пазлах, к которым относится, к примеру, Cover Orange, но и о стратегиях, фермах и других социальных проектах.

Конвертация у нас обычно длится не более шести недель для вновь полученного нагруженного проекта. При этом возможен сценарий, когда команда разработчика после конвертации продолжает делать игру на Flash, делает апдейты, которые мы, соответственно, переводим в HTML5 и выливаем уже на продакшн (подобный цикл обычно занимает для нас не более пары дней).

И что теперь?

Еще во время разработки мы поняли, что делаем решение не для себя, но в целом для рынка. Аналогов ведь нет, а спрос огромен как со стороны разработчиков, так и со стороны платформ.

Сегодня очень многие игры на Facebook, VK, OK, Armor Games, Kongregate, Poga Games и других площадках остаются на Flash. Однако сами разработчики не готовы их переносить на новую технологию.

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

Так мы приходим к ситуации, когда уже в следующем году площадки столкнуться с потерей 80% всего своего контента, а многие разработчики — своих доходов.

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

Как мы работаем с разработчиками?

Паблишинг у нас полного цикла.

Первый этап

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

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

Помимо этого, игру оценивают наши отделы маркетинга и QA. Только после этого мы отвечаем, интересен ли нам проект.

Второй этап

Подписывается контракт.

Третий этап

Конвертация проекта. Ее мы осуществляем сами с помощью вышеописанного инструментария.

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

Четвертый этап

Дистрибуция.

Мы стараемся охватить максимальное число площадок, в том числе не самые стандартные для HTML5-проектов:

• игровые порталы (более 150 сайтов, включая SpilGames и Miniclip);
• социальные сети («ВКонтакте», «Одноклассники», Facebook и так далее);
• мессенджеры (KakaoTalk, Telegram и так далее);
• мобильные сторы (App Store, Google Play и так далее);
• десктопные сторы (Steam, Epic Games Store, Gameroom и так далее);
• игровые зоны (The New York Times и USA Today и так далее).

Вот основные плюсы работы с нами:

• мы сами переносим игру на HTML5;
• мы паблишим игру на максимальном числе площадок;
• с этих площадок разработчик получает больше, чем если бы выходил один, поскольку тем же игровым порталам мы можем диктовать условия (мы приходим к ним с большим
• пакетом проектов, которые гарантированно генерируют игровые сессии);
• у нас планируется большая сетка проектов. К концу года у нас будет 600 проектов, которые будут обмениваться трафиком между собой.

Работаем по модели revenue share. Половина полученного дохода выплачивается разработчику, половина идет издателю.

***

Такая история. Если есть вопросы, обязательно задавайте.