Пользователь
0,0
рейтинг
28 марта 2013 в 01:50

Разработка → Mozilla предлагает создавать «тяжёлые» 3D-игры для web на их новом движке

Сегодня Mozilla совместно с игровой студией Epic Games выступила с инициативой создания визуально привлекательных 3D-игр, которые не должны уступать декстопным аналогам, и выполняться прямо в браузере.

Фактически речь идёт о том, чтобы перенести в веб опыт создания качественных, требующих высокой производительности, игровых приложений, которые должны будут выполняться обновленным движком JavaScript OdinMonkey, который недавно был включён в ночные сборки FireFox и скорость выполнения кода на Asm.js которым в 10 раз превышает аналогичный в других браузерах. Причём это всё без сторонних плагинов вроде Flash или Silverlight — чистый JavaScript.

Тот визуальный опыт, который должен получить геймер в интернете, играя в 3D-игру, предлагается оценить на видео ниже — так выглядит порт Unreal Engine 3, сделанный инженерами Epic Games и Mozilla:




Вторым преимуществом, помимо скорости, является возможность создания игр для мобильных платформ (Firefox OS ?) при помощи тех же инструментов, что и для десктопа. Mozilla на данный момент уже сотрудничает в этой области с Disney, Electronics Art и ZeptoLab для улучшения пользовательского опыта существующей базы игр этих производителей.

Разработчикам уже предлагается размещать свои новые игры и приложения в Firefox Marketplace.

[Источник]
Евгений @jeston
карма
80,2
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (52)

  • +38
    360p видео очень в тему
  • +7
    Пробежался по диагонали по ссылкам, но не совем понял, есть ли?
    1. многопоточность
    2. указатели
    3. SIMD
    4. структуры (value type без оверхеда, как в C#)

    Я просто сильно сомневаюсь в возможности реализации всего этого в модели javasctipt. Или я ошибаюсь?
    • 0
      Можете ознакомиться github.com/kripken/emscripten
      • +2
        Ну, emscripten транслирует биткод в стандартный javascript, который сам по себе ничего из этого списка «не знает». Надежда на новые API в asm.js, хотя они призрачны.

        Я это всё к тому, что я считаю, что «тяжелые» игры невозможны без этих четырёх фич. Причём именно в виде доступного API, а не на уровне скрытых внутренних JIT-оптимизаций. Буду рад ошибиться.
        • +2
          2,4 реализуется с помощью typed array формата «хапнем побольше» и низкоуровневой работы с ним. По-моему asm.js и должен так работать. UnrealEngine многопоточность не должна требоваться (она в нем не так рано появилась, поэтому что-то урезанное точно должно быть), остается SIMD? А так он ли нужен, если рендер на GPU?
          • +3
            Typed array действительно вариант! Костыльный, ограниченный только value type, но всё же вариант.
            А SIMD очень нужен. Даже в 2d играх, а тем более в 3d. Даже если рендер на GPU, всё равно куча математики (вся физика, как минимум, да и вообще) — векторная.

            PS: Ну и нормальная многопоточность тоже жизненно необходима. Не знаю, как обходились в Unreal Engine, но в эпоху 4-ядерных процов, работать в одном потоке просто глупо.
            PPS: WebWorker — не очень подходит, т.к. насколько я понял, не позволяет расшаривать данные между потоками, вместо этого в каждый воркер передается своя копия данных.
            • 0
              Про Web Workers. Во-первых, любой воркер может породить свои дочерние воркеры. И с ними общаться. Ну и ничего не стоит сделать канал между разными воркерами — это пара строчек).
        • +1
          Может тяжёлые и невозможно, но во многие старые лёгкие я бы играл в браузере с удовольствием
  • НЛО прилетело и опубликовало эту надпись здесь
  • –3
    Поправьте если я не правильно понимаю, но
    мы портировали унрил

    а это более миллиона строк кода

    Т.о. Каждый мало-мальски привлекательный 3d движок будет занимать более миллиона строк кода. Однако, если он поддается портированию, то объединенной командой, размером с mozilla и epic вместе взятых, можно портировать(не написать) сферическую игру в вакууме за 4 дня, без геймплея, монстров и оружия и сделать из нее непонятный ролик.
    Это определенно успех.
  • +7
    Риторический вопрос: как можно защитить игровой код — интеллектуальную собственность компании-разработчика? Даже если собственно игры, выполненные на этой технологии, будут бесплатными, желание не давать исходники всему миру вполне понятно и объяснимо.
    Сам принцип работы JS недружелюбен к «ААА»-проектам, на которые инженеры Мозиллы хотят замахнуться.
    • +5
      Вообще не пойму что дает выполнение в браузере для таких игр. Все равно играть лучше в полноэкранном режиме, и какая разница будет ли это окно браузера или отдельное приложение. К тому же качать сотни мегабайт яваскрипта как то не айс. Проще пойти и купить диск. Для каких нибудь онлайн магазинов, презентаций это хорошая штука будет, но не для игр.
      • +2
        Думаю переключение фулскрина точно будет, если еще нет. А на дисках игры все меньше покупают, с развитием магазинов вроде стима
      • 0
        Выполнение игры в браузере дает неплохую кросплатформенность для всех платформ где этот самый браузер может запускаться, что в свою очередь дает больший охват аудитории игры и в перспективе больше денег разработчикам/издателю. Другой вопрос как эти игры будут защищать — одно дело бинарники собрать для разных платформ, а тут открытый код всего: и движек, и логика, и графика со звуком — не думаю что производители топовых игр захотят такого.
        • +2
          Ну не такой уж и открытый — «курить» десятки и сотни мегабайт минимизированного JavaScript-кода: задача, вполне сравнимая по сложности с разбором байт-кода JVM или .NET

          Зато, с другой стороны, можно прикрутить красивый API для модов, плагинов и прочего :)
      • 0
        Fullscreen API в современных браузерах уже есть :). Сотни мегабайт JS… Помнится, был порт Unreal Engine на флеш и про подобные проблемы я не слышал… Хотя может они и были, я, если честно, далёк от флеша
    • НЛО прилетело и опубликовало эту надпись здесь
      • +8
        Ну нифига ж себе, вы сравнили…
        Да самый заобфусцированый вдоль и поперёк js — это ничто, по сравнению с дизамблированным C++. Даже используя что-нибудь вроде IDA, разобраться в биткоде — это на порядок более сложная задача. Да что там на порядок, это зачастую просто несоизмеримо.

        К тому же, любая более-менее серьёзная обфускация js (с eval'ами, фейковыми объектами и прыжками по меткам) тормозит by design. Для игр не подходит.

        havelock прав, за что минусы не понятно.
        • +5
          Там JS используется фактически в качестве ассемблера, от исходной программы в нем остается не больше чем в x86 коде.
          • 0
            промахнулся с ответом
        • +3
          Так в приведенном случае использовался javascript llvm-backend. От дизассемблированного кода на C++ это будет не сильно отличаться.
    • 0
      Сам принцип работы JS недружелюбен к «ААА»-проектам, на которые инженеры Мозиллы хотят замахнуться.

      Какие ещё ААА? Использование движка Unreal не делает из игры ААА. Думается мне, что в силу ограничений и тормознутости JS даже после всех оптимизаций, в первую очередь будут реализованы нетехнологичные игры, которые не грузят проц и видюху топового железа на 100%.

      А для игр, в которых не так критична производительность, уже сейчас успешно используются .NET и Java, которые даже после обфускации обычно неплохо декомпилируются. И вообще, у относительно малого количества игр есть какие-то хитрые алгоритмы, которые ну никак нельзя раскрывать конкурентам. Ну, игроки чуть быстрее выяснят вашу формулу вычисления дамага или ещё какую-нибудь мелочь.

      В Стиме дофига успешных игр на .NET и Java, некоторые даже не обфусцированы, ресурсы тоже очень часто незашифрованы. И что-то я не вижу, чтобы эти игры чаще или реже выкладывались на торренты, потрошились конкурентами, и вообще с ними происходили какие-то особые катаклизмы.

      Не надо так трястись на битами и байтами. Берите пример с Джона Кармака, например.
  • 0
    Подозрительно знакомое демо. Хотя то, что производительность JS постепенно подтягивается до производительности Flash безусловно радует.
    • 0
      Будет подтягиваться, но никогда не превзойдет без изменения языка.
  • +4
    Очень любопытно насколько реализация UE3 под мозиллой требовательнее к ресурсам компа, в сравнение с обычным UE3…
  • –4
    Т.е. если раньше разговор шел о том, что с игрой надо было (точнее, автоматом вставали) нужные системные библиотеки, то теперь в качестве зависимости будет вставать, ни много ни мало, браузер?

    Чего только не придумают, чтобы повысить процент своего присутствия на рынке. :)

    Правда, я бы такого хода ождал от MS с их IE, от Яндекса с их Баром, тьфу, Яндекс.Браузером, даже от Рамблера или Mail.ru, но не от Mozilla. Им-то всегда как-то не особо была важна раскрутка «сторонними» методами…
    • +5
      Корпорация добра уже давно как на этом пути: NaCl.
      И это не столько попытка попытка завязать на себя, сколько удовлетворение прогнозируемого в ближайшем будущем спроса.

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

      Например, даже Microsoft похоронила свой XNA, и призывает back to the native С++ в игропроизводстве. Именно по причине производительности. А ведь XNA (.net) это даже близко не JS и не браузер.
      • +5
        Мне почему-то кажется, что здесь имеет место игра в «важно возглавить поток». У Спольски об этом очень хорошо было написано, что цель компаний типа MS — изобретать все время новые парадигмы, чтобы все гнались за ними, а когда приблизятся — изобретать новую, что оставляет у всех ощущение движения, а лидера все равно не догнать, т.к. за счет таких правил именно он диктует правила игры.

        Старые подходы в играх никуда не делись: игры пишутся, тестятся, все работает, но надо же как-то движуху создавать?
  • 0
    Интересно, как будет организовано хранение данных и кода игры — все локально или будет требовать постоянного подключения к интернету. Очень надеюсь на первое.

    Как бы то ни было, со стимом под 3 основные платформы не вижу причин играть во что-то через браузер.
    • 0
      Думаю, это больше для людей, которые играют в социальных сетях. Сейчас игры там довольно однообразные, мультяшный флеш, как правило. Игры на Unity в социальных сетях как-то не встречались, кроме одного клона Майнкрафта, чтобы играть в который нужно постоянно донатить.
      • +1
        • 0
          Так же он есть еще на Facebook'e, Android'e и iOS и можно использовать один аккаунт, но все это больше заслуга unity, и да, без вливания денежек это абсолютно неиграбельно.
    • 0
      Технологии хранить все локально в браузерах давно есть:
      LocalStorage, IndexedDB, AppCache.

      Краткосрочный успех непонятен, долгосрочный — почему нет?

      Веб-приложения наступают с лоу-енда — сначала казуальные игры. потом посильнее, потом еще сильнее…
      Если делаешь игру не с супер крутой графикой, а берешь геймплеем, то выигрыш очень силен — не надо портировать на кучу платформ.
      • +1
        Я просто надеюсь, что мы не придем к ситуации, когда все игры будут требовать подключения к интернету. А насчет портирования — мне кажется, что и так давно все идет к кроссплатформенным приложениям (в основном играм). Плюс не думаю, что такое количество разработчиков нативных игр и компаний, которые занимаются этим, перейдет на новые технологии, успех которых пока еще сомнителен.
        • 0
          Не все сразу :-)

          Когда-то и текстовый редактор в браузере был сомнителен.
          И люди на десктопе использовали клиенты, чтобы писать в блоги (типа семаджика).
          • 0
            Одно дело текстовый редактор, а другое — 20 гигов ассетов.
            • 0
              А какая разница? AppCache эту проблему решает
              • 0
                К сожалению, я почти не знаком с разработкой под веб, чтобы рассуждать на такие темы. В целом если смогут сделать сервис на уровне стима, то может чего и выйдет. В любом случае, я в принципе согласен, что такое когда-нибудь сделают, но просто сомневаюсь, что в скором времени.
  • 0
    Особенно будут рады новостям об OdinMonkey и Asm.js непримиримые любители нативных мобильных приложений.
    • 0
      Под iOs не появится OdinMonkey, так же как FireFox, так же как опера там не появилась на Presto. Так что остается только нативный код.
      • 0
        Речь не о том, где и что (или кто) появится или нет… речь в принципе об используемых технологиях для мобильных приложений. Apple конечно же пойдет своим путем, никого не пустит на свою платформу. Но вопрос в другом — в каком именно направлении все это будет двигаться. Сейчас только и разговоров о том, что под мобильные приложения возможен только натив и никак иначе. Но так ли это на самом деле?
        inet777.ru/buduschee-mobilmznyih-prilozheniy-nativnyie-ili-html/8401
        • +1
          Вы правда предлагаете читать километровую статью по мобильной разработке на сайте дизайн которого застрял в 90х?
          А на самом деле есть яркий пример ФБ, который сделал ставку на HTML5, потом признал свою ошибку и несостоятельность такого варианта и переделал под натив. И мне пока не известны примеры успешных приложений, особенно хоть сколько нибудь требовательных к ресурсам и написанных не на натив коде.
          • 0
            1. о вкусах не спорят — это я о дизайне, на вкус и цвет… мне нравится — этого достаточно! более ничье мнение насчет дизайна сайта меня не интересует
            2. на Цукерберга мы еще поглядим… еще не достаточно времени прошло, чтобы делать какие-то выводы… я думаю, те 2 года, что он занимался HTML5 он был точно так же абсолютно уверен в правильности выбранного им пути… но рановато пошел по нему… поглядим, что будет в последующие 2 года перехода ФБ на натив
          • 0
            «И мне пока не известны примеры успешных приложений, особенно хоть сколько нибудь требовательных к ресурсам и написанных не на натив коде. „

            Я считаю, что как раз технологии подобные OdinMonkey и Asm.js как раз и помогут это решить.
          • 0
            ФБ не делал ставку на HTML5. Это были его собственные расширения для HTML.
            • +1
              А что такое расширения для HTML? Особенно в контексте мобильных приложений?
              • 0
                У фейсбука было не приложения HTML5, а собственный диалект HTML с расширениями, которые выполнялись в кастомном браузере с специальным плагином.
                • +1
                  А можно линки, где об этом почитать можно, аж интересно стало. Особенно учитывая что Apple не пускает на iOs альтернативные браузерные движки.
  • +6
    Интересно а как гуглевский Native Client развивается? Потенциал у этой технологии, мне кажется, больший, чем у ускоренного js с 3D.
    • 0
      Из последних новостей — переход на новый прокси, который облегчает обращение к браузеру в многопоточных приложениях, появление отладчика на основе gdb (при этом можно отлаживать даже на Chrome OS без переключения в dev-режим) и плагина для Visual Studio 2010 (нужна полная версия), появление компилятора для arm'a на основе gcc, исправление бага хрома с повреждением скачиваемых nexe, исправление багов с CORS. В ближайшем будущем собираемся перейти на новый валидатор, который в несколько раз быстрее старого, что должно немного ускорить запуск приложений.
  • +1
    Местами похоже на машинный перевод.
    «визуальный опыт» (очевидно «visual experience»),
    «для улучшения пользовательского опыта» (очевидно «user experience»).

    по теме — при использовании asm.js они расчитывают получить код, который выполняется всего вдвое медленнее, чем нативный (буквально на днях была об этом статья), учитывая, что сейчас получаются довольно неплохие игры, работающие на мобильных устройствах, то написать игру, которая не будет тормозить в десктопном браузере — реально. А целесообразность покажет время.
  • 0
    fightcodegame.com/robots/replay/761152 Нашел смачный бой ))))

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.