Игры в браузере (часть 1)

mainВчера читал доклад на небольшом местном мероприятии GamesLab.

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

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

Существует 2 варианта сделать игру для браузера: npapi плагины и html5.

Самые популярные плагины: flash player (дальше по тексту просто flash) и unity web player.

unityDПосле того, как Google решил убить NPAPI из-за проблем с безопасностью (и правильно сделал), unity web player умер. И дело даже не в том, что он больше не работает в хроме, а в том, что сама компания Unity объявила о прекращении развития и поддержки плагина.

Ребята, разрабатывающие Piratecraft, поделились информацией:

после первого этапа отключение npapi в хроме (когда все еще можно было активировать unity плагин вручную через настройки) процент поигравших, среди вновь установивших игру, стал значительно ниже (да и в общем процент «технических отвалов» всегда был выше по сравнению с тем же flash).

flashА вот Flash Player выжил.

Компания google решила, что умирать flash пока рано. И стала вместе с компанией adobe разрабатывать версию для chrome, которая основана на новом api для браузеров ppapi. Кстати говоря, люди очень жалуются на то, что pepper flash в chrome значительно хуже работает, чем npapi flash в других браузерах.

Я не стану агитировать начинать разработку с flash, если вы до этого с ним не работали. Но вот несколько плюсов «на подумать»:

  1. На ActionScript3 огромное количество библиотек и готового кода, который можно использовать в своих проектах. Если вы нашли пример кода 2011-го года — он все еще не потерял актуальность. Все будет работать и прекрасно выполнять свои функции. Все это огромная база для обучения и конечного использования. Так же сама простота, с которой можно получить конечный результат, поражает и является серьезным плюсом.
  2.  Flash все еще востребован. После всего шума вокруг его смерти многие бросили технологию, а, между тем, большое количество проектов как разрабатывались, так и разрабатываются на flash. Мне приходит много предложений на linkedin. Работы так же хватает и на upwork, и на freelancer.com (специально изучил спрос)
  3. Можно быть ИНДИ! Все же хотят быть инди? =) Пока одни бежали с flash, другие продолжают делать и продавать игры порталам. Конечно, нет уже тех дурманящих разум цифр, но заработать на жизнь можно (подробнее в следующей статье).

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

Идем дальше, что же такое HTML5?

html5

HTML5 — это не язык разметки.

HTML5 — это набор технологий для разработки web приложений.

Нам, как разработчикам игр, в первую очередь интересны следующие технологии:

 

  • javascript — язык программирования;
  • canvas — отрисовка простой 2d графики;
  • webgl — низкоуровневая и более тяжелая отрисовка 2d и 3d графики.

Коротко про плюсы:

  1. Основным плюсом HTML5 является его кроссплатформенность. В теории, он должен работать на всём, где есть браузер. И когда-нибудь так и будет. А пока, все дружно ждем светлого будущего и ставим костыли, чтобы все работало хорошо и на максимальном количестве платформ.
  2. Ситуация с библиотеками не хуже чем на flash. Большинство библиотек и инструментов с открытым исходным кодом (закрыть исходный код js не так уж и просто)
  3. Таргет для экспорта из популярных движков (unity , unreal engin и т.д.).

Из-за особенностей технологии и спроса на игры, написанные на HTML5, стоит отдельно рассматривать HTML5 WebGL и HTML5 Canvas.

webgl

HTML5 WebGL — «толстый». Он работает быстрее, т.к. отрисовка идет на видеокарте. Но это же является и минусом, т.к. он поддерживается на меньшем количестве платформ. Больше всего с этим проблем на «стоковых» (встроенных в прошивку телефона) браузерах чуть более старых телефонов.

canvas

 

HTML5 Canvas — «тонкий». Но в тоже время и «хилый». =) Он поддерживается на всех устройствах (ну кроме откровенной древности). Но при этом производительность оставляет желать лучшего. Несколько движущихся объектов уже могут стать проблемой(очень сильно зависит от браузера и устройства).

Коротко сравним плюсы и минусы платформ. Можно придумать тысячи пунктов для сравнения, но я остановился на этих трех:

table

  1. Чем меньше билд, тем больше пользователей дождутся загрузки игры и поиграют в нее.  У flash и Canvas с этим все хорошо и, в первую очередь, упирается в ресурсы самой игры (графика,звуки и т.п.). А вот на WebGL все чуть хуже. Если это экспорт из большого движка, то он потянет за собой свои «толстые» библиотеки, необходимые для работы. На специально «заточенных» WebGL  движках с этим лучше.
  2. Поддержка на мобильных устройствах следующий важный, по моему мнению,  пункт. Flash, по завету Стива, не поддерживается в мобильных браузерах (но собрать мобильную версию приложения в стор можно!). С html5 все лучше, в конце концов, в этом его сильная сторона. WebGL на свежих телефонах  работает очень даже не плохо. По крайне мере, на движках под это «заточенных»(например: threejs). С экспортами из unity и unreal все по прежнему плохо. Даже если игра работает, то весьма не стабильно.
  3. Что касается ограничения по жанрам, то тут в лидерах WebGL. По сути, на нем можно сделать все, что душе угодно. Но чем «навороченнее» игра, тем меньше платформ она будет поддерживать. С flash тоже все весьма не плохо. Но многие жанры делать просто нецелесообразно. А вот canvas — сплошное ограничение. В первую очередь из-за производительности. Кроссплатформенность требует жертв. =)

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

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

Буду рад вашим комментариям.

Спасибо.

P.S. Повторюсь, что статья во многом капитанская. Но это обусловлено аудиторией доклада, которой я читал (во многом это студенты).

UPD: Большое спасибо Sergey Batishchev за комментарии. Внес изменения   в статью.

  • Sergey Batishchev

    Норм в целом! 🙂

    > canvas — отрисовка 2d графики на CPU;

    Не — это неправда. Открой chrome://gpu и прочитай первую строчку. На CPU даже скроллинг вебстраниц не взлетел бы на мобилах (см. 5ю строчку на этой же странице). На всех без исключения современных браузерах (включая мобильные платформы) canvas аппаратно ускорен.

    В целом на будущее я бы подыскал какую-то более точную аналогию про Canvas vs WebGL. Они, скорее, соотносятся друг с другом как GDI и Direct X на Windows. Первый — высокоуровневый. Второй — низкоуровневый. При этом оба исполняются на современных ОС (Win 7 и выше) на GPU.

    Наверное, нужно упомянуть PIXI, который умеет рендерить и в WebGL, и в Canvas.

    Ну и эта. Где-то 50-100 небольших объектов без проблем в канвасе рисуются на телефонах. А это уже больше, чем несколько! 🙂 http://html5devgamm2014.bitbucket.org/purecanvas-sprites.html?100

    • Огромное спасибо. Поправлю.

      А вот про 100 объектов не соглашусь. Очень зависит от телефона и браузера. Хотя тоже стоит внести некоторые исправления.

      • Sergey Batishchev

        > Очень зависит от телефона и браузера.

        Без сомнения!

        По ссылке — рисование N объектов на канвасе 640×712 (чистый канвас, даже стирание не делается — просто как «верхняя граница»). Если есть у тебя какой-нибудь старый телефон, можешь протестить и вставить «пруфлинк», как там на самом деле дела обстоят. 🙂

        • вот видео
          https://youtu.be/jtUJZvrSVm0

          Мои эталонные устройства:
          Первый:
          huawei u8825D
          android 4.0.4
          Adreno 203
          Результат:
          в хроме демка работала с 8-9 fps
          в стоковом браузере игра просто не запустилась.

          Второй: iphone 5c
          на видео стабильных 60 фпс
          но это когда уже поработает.
          как только открываешь полностью закрытый браузер то секунд 20 скачет от 50 до 60 фпс потом выравнивается на 60 фпс.
          В общем то результат хороший.

          Так же протестировал xiaomi redmi note 2 (этого нет на видео, но могу записать если надо)
          Mediatek MT6795
          PowerVR G6200
          android 5.0.2
          cтоковый браузер 10 фпс
          chrome тоже 10 фпс
          а вот firefox около 40 fps
          результат очень расстроил т.к. устройство не самое хилое в общем то.

    • Что касается pixi , то во второй статье упомяну, когда буду про «куда податься с игрой» рассказывать.

    • Справедливости ради — Pixi рендерит в CPU такие вещи на канвасе, которые не возможны на WebGL. Мне другое любопытно. Много кто говорит, что Canvas без WebGL работает с GPU ускорением. Только я не видел ни одного случая, где это было бы заметно ) Если html5 игра тормозит — почти без сомнений это canvas без webgl.

      • Sergey Batishchev

        > Только я не видел ни одного случая, где это было бы заметно

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

        На ПК под Windows или Mac:

        Часть первая:
        1. Зайди в chrome://gpu. Убедись, что Canvas: Hardware accelerated.
        2. Запусти демку по ссылке http://html5devgamm2014.bitbucket.org/purecanvas-sprites.html?1000 (это просто в цикле вызов 1000 drawImage из большого спрайтшита). Какой FPS?

        Часть вторая:
        1. Зайди в chrome://flags. Включи опцию: «Отключение ускорения двухмерного элемента canvas Mac, Windows, Linux, Chrome OS, Android. Для обработки двухмерного элемента canvas будет использоваться не графический процессор, а программная отрисовка. #disable-accelerated-2d-canvas». Обрати внимание, у этой опции «обратная» формулировка — ее нужно включить, чтобы аппаратное ускорение отключилось.
        2. Полностью выключи Хром (может потребоваться нажать на иконку Chrome в панели винды правой кнопкой —> выход, или для надежности перегрузиться).
        3. Проверь, что в chrome://gpu значение стало Software only. Hardware acceleration disabled. Если нет, нужно проверить еще раз значение флага, и проверить, что Хром и правда перестартовал.
        4. Запусти демку http://html5devgamm2014.bitbucket.org/purecanvas-sprites.html?1000. Какой FPS?

        • >>> 1. Зайди в chrome://gpu
          Я не пользуюсь хромом для игр. Firefox наше всё 🙂 В хроме 58-60 фпс. Скрипт не покажет ничего особого, т.к. нет clear всей области, что собсна делается в играх 🙂

          >>> Часть вторая:
          32 FPS

          По твоему совету я проверил и понял, что ускорение гпу у канваса доступно!
          Остается понять почему фпс в этом примере отличный, а у игр разных — низкий

          • Sergey Batishchev

            > Я не пользуюсь хромом для игр. Firefox наше всё

            На FF ситуация похожая (канвас рисуется на Direct2D), но я плохо знаю технические аспекты FF и не смог бы из головы написать инструкцию. Хочу перейти на пару месяцев на FF (а потом на Safari), чтобы не становиться заложником хрома! 🙂

            https://hacks.mozilla.org/2010/09/hardware-acceleration/

            > По твоему совету я проверил и понял, что ускорение гпу у канваса доступно! Остается понять почему фпс в этом примере отличный, а у игр разных — низкий

            Пример шибко «синтетический» (один целевой канвас, рисуется из одного большого спрайтшита, не делается очистка).

            В реальной жизни из-за высокоуровневости канваса браузеру приходится тяжко. Ведь программист не может управлять аспектами оптимизации, и браузеру приходится «угадывать»:
            — Какой канвас использовать: аппаратный или программный (для канвасов меньше 256×256, например, Хром может решить использовать программную реализацию).
            — Когда загрузить и выгрузить изображения
            — Как и когда делать «батчинг».

            При этом угадывать тяжело, так как для браузера это же просто веб-страница. Например, он не знает, что это «центральный контент» и нужно делать его 60 FPS любой ценой. И не может быть уверен, что, скажем, это не страница типа ленты фейсбука, куда вот-вот будут со скоростью пулемета догружаться и выгружаться фоточки котиков.

            Поэтому WebGL гораздо в этом отношение линейнее — всеми этими вещами управляет программист.

  • Отлично! От себя добавлю, что есть такое средство разработки, как Haxe. Он позволяет выгонять как флеш, так и html5. Это не считая уже и мобилу + десктоп.

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

    • Да. Спасибо.

      Я не рассматривал инструменты разработки т.к. тема очень обширная. И на это нужен целый цикл отдельных статей.