Search Unity

Разработка для веба после отказа от NPAPI в Chrome

, Май 28, 2015

После того, как Google отказался от NPAPI в браузере Chrome, мы стали получать вопросы о том, как лучше всего публиковать игры в вебе и одновременно добиться внимания пользователей Chrome. Учитывая широкое использование Chrome, эти вопросы вполне закономерны.

Прекращение поддержки NPAPI

Если вы создаете веб-игры и слышите обо всем этом в первый раз, вот на всякий случай краткий обзор происходящего. В 2013 году Google сообщил, что прекращает поддержку NPAPI – фреймворка плагина, на который опирается Unity Web Player. В настоящее время ведется работа, чтобы вернуть поддержку NPAPI в Chrome, однако Google планирует полностью отказаться от NPAPI из Chrome в сентябре 2015 года. Что касается других браузеров, нет точного времени прекращения поддержки NPAPI и в них, но это произойдет.

Сразу после этого анонса мы начали серьезно исследовать альтернативные способы для веб-игр. Мы решили развивать WebGL, о чем сообщили на GDC 2014; сейчас он доступен в превью в Unity 5. Вы можете прочитать об этом более подробно в данном посте: http://blogs.unity3d.com/ru/2014/04/29/on-the-future-of-web-publishing-in-unity/

Состояние WebGL

Очевидным решением кажется создание игр на WebGL. В итоге это решение будет превосходным, сейчас мы активно работаем над WebGL с разработчиками браузеров из Mozilla, Google и Microsoft. Но сейчас базовая технология WebGL все еще имеет ограничения в сравнении с Unity Web Player. Это включает и разницу в производительности, над чем мы работаем, хотя это очень непросто в силу очень большого количества вариантов в производительности в разных браузерах. Подробнее о производительности WebGL можно узнать в данном пост: http://blogs.unity3d.com/ru/2014/10/07/benchmarking-unity-performance-in-webgl/

В своем нынешнем состоянии WebGL отлично подходит для «легких» веб-игр и приложений, но очень важно задать реалистичные ожидания. Вы вряд ли сможете просто перенести игру из Web Player и ожидать, что все будет работать прекрасно. Для тяжелых игр с высокой производительностью WebGL, скорее всего, не является в настоящее время удовлетворительным из-за вышеупомянутой разницы в производительности, некоторых других ограничений платформы, таких как нетворкинг, масштабируемости из-за размера билдов и ограничений памяти самого браузера. Так как эта технология все еще активно разрабатывается как с нашей стороны, так и разработчиками браузеров, мы, к сожалению, не можем предоставить поддержку, в том числе в рамках нашего Premium Support, пока не будет выпущен финальный релиз. Одновременно мы призываем вас обсуждать вопросы, связанные с WebGL, на форуме http://forum.unity3d.com/forums/webgl.84/, участниками которого являются наши разработчики.

Но нет худа без добра!

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

Состояние Unity Web Player

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

Также очень важно отметить, что Unity Web Player отлично работает в других браузерах, кроме Chrome, так что есть варианты.

Итак, что мне делать, если моей игре нужен Web Player?

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

Опция B: Предоставьте инструкцию, как запустить плагины в Chrome (сейчас нет способа запустить плагины NPAPI). Пример инструкции ниже:

Шаг 1: В адресной строке Chrome наберите: chrome://flags/#enable-npapi

NPAPI enable 1

Шаг 2: Найдите функцию «Enable NPAPI Mac, Windows» в списке и кликните «Enable».

NPAPI enable 2

Шаг 3: Нажмите кнопку «Relaunch Now» внизу страницы.

NPAPI enable 3

Что делать, если я работаю над новым проектом?

Тем, кто создает новый веб-проект с Unity, мы рекомендуем начать его с Unity 5 WebGL. Игры на WebGL более ограничены с точки зрения функциональности и производительности, нежели игры с Web Player, поэтому вы можете портировать игру на Unity 5 Web Player позже, если хотите добавить дополнительную функциональность. В этом случае игроки смогут играть в WebGL игру через Mozilla Firefox, Google Chrome, Apple Safari 8.x или играть в игру с Unity Web Player с помощью Microsoft Internet Explorer, Apple Safari 7.x или Яндекс.Браузер. Такой подход позволит завоевать широкую аудиторию игроков.

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

Резюме

WebGL будет удивительным – даже лучше, чем Unity Web Player, так как у игроков не будет барьеров в виде плагинов. Но все мы должны понимать, что сейчас эта технология не обладает такими возможностями, как Unity Web Player, и пока нет равнозначной замены, которая поможет избежать устаревание фреймворка. Мы понимаем, что это не самый простой путь, и мы разделяем вашу боль, так как мы очень любим Web Player. Но, к сожалению, не мы принимаем решение. В настоящее время, если вы поддерживаете очень сложную игру, которая должна хорошо работать в вебе, вам нужно использовать Web Player и рекомендовать игрокам использовать другой браузер.

Мы, в свою очередь продолжим работать с разработчиками браузеров, чтобы сделать платформу WebGL и наши собственные инструменты WebGL таким мощными, какими они, как мы знаем, могут быть!

Комментарии закрыты.

  1. I appreciate that it’s not Unity’s fault but AGAIN I have to pay a lot of money I really don’t have, as I’ve spent loads on Unity but made Nada ( freely admit I must be doing it wrong) to upgrade my license to the «new» version to get something that doesn’t work as well as it does now but shortly won’t work at all anyway because of Eternal Web browser infighting.
    It’s hard to hold on to the will to live.

  2. I think Unity should create their own browser. One of your recommendations was to have people use an alternate browser anyway. And users have always needed to allow the installation of the Webplayer the first time they clicked a webplayer link, so why not a small completely optimized Unity browser for Webplayer content.

    The more I think about this, the better it sounds. I do ArchVis, and the biggest advantage for me using the Webplayer is clients don’t need to download anything new. If I make some changes, they just hit F5. And i’ve never embeded anything anyway, I always use a new clean window. It could evolve into a front end for all things Unity Webplayer related.

    1. Perhaps I’m missing something, but for my clients it would be just as much «friction» to ask them to download a custom Unity web browser as it would to just have them download a native app. The whole promise of the web browser as a target (which has yet to be fully realized) is to eliminate requiring your clients to download something special.

      1. But they would only need to download it once. Currently if I am providing a standalone player, they need to re-download the entire project every time there is an update. There is also the problem of outdated builds floating around. With an interface, think Steam for Unity web content, the one install would access all updates and any future projects in one place.

  3. The sad truth for me is that WebGL isn’t going to be ready enough in September, when Google kills NPAPI. My games are realtime, multiplayer and they use UDP communications. Our business model requires that we’re in the browser and many of our clients (educational institutions) have standardized on Chrome (often, even Chromebooks) because of Google’s services and web apps. Why can’t Unity engineers work with Google engineers to make ARC (App Runtime for Chrome) Welder work with Unity built APKs? At this time, it simply doesn’t work. Even the simplest of ‘Hello World’ apps created in Unity3d fails to launch when run through ARC Welder.

  4. The sad truth for me is that WebGL isn’t going to be ready enough in September. My games are realtime, multiplayer and they use UDP communications. Our business model requires that we’re in the browser and many of our clients (educational institutions) have standardized on Chrome (often, even Chromebooks) because of Google’s services and web apps. Why can’t Unity engineers work with Google engineers to make ARC (App Runtime for Chrome) Welder work with Unity built APKs? At this time, it simply doesn’t work. Even the simplest of ‘Hello World’ apps created in Unity3d fails to launch when run through ARC Welder.

  5. Google is hurting us too… the removal of NPAPI is hurting the users of our enterprise application we use here. So we just ‘force’ the users to either use Firefox or IE.

    Chrome’s loss.

  6. I have use WebGL on my machine and Firefox disabled it because my graphic card is supported.
    Of course I can Enable WebGl and it work fine when I use it with engine like Pixi.js
    But none of the demo on the asset store using WebGl works.
    Chrome use to be my default browser but when NAPI’s been deprecated I have just switch to Firefox,
    maybe everyone should do the same and we can keep the amazing Unity WebPlayer.
    I mean so much work have been put into that.

    1. The millions of Flash guys say ohai…

      Seriously though — the web has become something of a sacred cow and until Unity fully supports ‘their’ way of doing things, the only option will be to develop using webgl.

  7. Uh.. 1 or 2 more years to have WebGL at level of current WebPlayer.. that is quite a lot.
    Also is WebGL build transforming all Unity dlls into JavaScript all the time? Doesn’t that change only after some Unity patches are being applied, so theoretically it can be cached and removed only with new Unity patch or version.

  8. Why not just port the Unity engine to the the Chrome Portable NAtive CLient API? We just completed our transition to this technology and are satisfied with the performance and features set — best of all is support for C++ 11 and multiple threads.

    The developer tools were very difficult, some bugs took weeks to address, but in the end we managed to get our 3D engine up and running on Chrome just fine. The PEXE format is quite flexible too, requiring only a single file to support 32-bit and 64-bit clients on Chrome for Windows, Mac, and Linux. It’s really an amazing piece of cross-platform technology. I can’t stress enough the difficulty of the tools though — it may not be for everyone — some debugging sessions will have you thinking about a career change. I really wish Google would spend some money on better tools.

    Sooner or later, every Browser will provide a similar API — a platform for just-in-time compiled native-code components that enable the ultimate web experience, utilizing all the power of that awesome laptop or desktop computer you spent your hard-earned money on. Waiting on the web standards organizations or monopolistic mega corporations is a great strategy for low performance and a ho-hum experience.

    1. Unity already had NaCl support long time ago but I think the support was dropped due low usage vs the costs of maintaining the platform to have all fixes and new features. There was also Flash support which would not have been limited to single browser but it was killed too for some of the same reasons. I don’t think there is any point to implement any deprecating technologies or one browser only solutions. By the time they would have some Chrome specific solution out there in good shape there would be other browser announcing the death of plugin support. I think it was already said Windows 10 default browser wont support em either(?)

  9. just improve webgl/html5 apps for all browsers and we are all happy. no other solution!

  10. That’s sad. Developers ignore my questions about making WebGL building on x86 OS possible.
    I replaced both x64 Python and Emscripten folders with x86 ones but it still fails to build on x86 OS . . .
    Any suggestions how to build WebGL on x86?

    Well, if developers of Unity are silent — then what do You think about it, guys?

    1. Well you asked it before in the wrong blog post which had nothing to do with web publishing.

      I think it was said long time ago during U5 beta when someone asked similar question that there were no plans that moment to support 32bit tool chain while the WebGL is only at preview state. I think one of the reasons possibly was memory requirements and one was the thing Jonas said in comments below that emscripten will be replaced with native executable.

      1. Thanks for comment, Zirkonium! Looking forward for the replacement . . .

  11. What bugs me about this blog post is Google didn’t do this overnight and someone who develops one of the most widely deployed plugins on the web like Unity should have known this was coming months, if not a year, in advance.

    Then you make this post where you make it sound like you didn’t know it was happening till the day it happened and then tell people to switch browsers, play with settings they should not be playing with (and won’t figure out) or use your horrible (10 minute+ build times — fix one line of code and wait another 10+ minutes for the next build) webGL.

    The web is a very important platform to support, don’t fail it like you did here Unity.

    1. We are certainly not trying to imply that this is something that came overnight and the timeline of awareness is clearly outlined in the blogpost.

      We completely share your sentiment on the importance of webpublishing. This is why we are heavily investing in the future of Unity games web-publishing; WebGL. Unfortunately, Google’s decision to pull NPAPI came before browsers are ready to offer completely parity without plugins. While that on itself is a negative at the same time we are continuing our work with browser vendors so parity can be reached in the future.

      Working on WebGL for over the last 3 years, we’ve stood at the cradle of the technology needed to truly replace plugins on the web. We don’t believe it’s there today yet, but we will continue and push the web as a platform.

    2. Yeah, I didn’t get the sense at all that they were implying any bit of surprise, and like Ralph said, the post clearly outlines Unity’s activity from the very beginning. You say Unity should have known this was coming a year in advance… They knew well MORE than a year in advance; that’s sort of why they have a beta webGL build function right now.

  12. I disagree that Unity3d WebGL is only for «light weight» games & apps.

    My project is putting the 1999 MMORPG «Everquest» in WebGL. Been great so far.

    http://eqbrowser.com/play/

    1. That game came out 16 years ago.. by any metric it’s not a good example to prove your point (unless your point was a shameless plug, in which case- kudos). I hear they’ve got Doom running on toasters and refrigerators now too.

      My company’s attempts to do anything approaching the level of complexity or visual fidelity that we could get out of the web player have been met with disappointment and frustration. WebGL is simply not ready for prime time beyond simple games and applications (and that includes even the most cutting edge games that came out in 1999).

      1. I think for most of our users, the measure of complexity would primarily be «on parity with WebGL». Today, there’s many cases where we can’t make that happen, due to limitations as the plugin-less web/browser as a platform.

  13. Even with the same abilities as WebPlayer, WebGL still wouldn’t be as good, because you need a server to host it, right? You can’t just stick it into a dropbox to share with people.

    1. Tristan Bellman-Greenwood

      Май 28, 2015 в 11:04 пп

      The built product using WebGL consists of a collection of files, just like the Web Player does.

      Both of these options require servers to run (that’s how the data gets distributed) but in your case, you are using the Dropbox servers to host your Web Player game.

      You could host your WebGL game on Dropbox but you may need to edit the files that Unity builds to refer to the URLs that point t the files that the project needs.

      I would, however, suggest getting an AWS account and putting your files in S3. For a few cents per month you can host your files without changing them after Unity builds them.

    2. There should be no problem copying the deployment folder to your dropbox folder and sharing the public url for the the entry html file.

  14. on the last Chrome update, chrome is not highliting NPAPI option when entering that command on the nav bar. And there is a warning prompt that warns the user not to do it… And the prompt says that on chrome 45 that trick wont work either.

    They have their own flash implementation to avoid npapi so you should find an agreenent with them. Unity is becoming huge and they know it. I’ve worked with webgl before and due to performance is why Unity was my choice :(

    1. Jonas Echterhoff

      Май 29, 2015 в 9:25 дп

      They have their own Flash implementation using PPAPI, but I don’t expect that they will keep that route open longer then they have to. PPAPI essentially shares all the security issues with NPAPI, so I expect it will only be a matter of time until Google will stop supporting this as well — they only reason they can’t do that yet, is because Flash content is still so prevalent on the web (much more so then Unity or any other plugin). But it is declining quickly.

  15. Build times are key for us right now — IL2CPP + emscripten takes 5-8 minutes to build our project. It makes any form of development impossible. It would be great to hear some more info from Unity about general expectations for the true 1.0 version of WebGL publishing. Is there work in the pipeline that should bring the builds to a manageable duration?

    1. Jonas Echterhoff

      Май 29, 2015 в 9:28 дп

      Yes, this is a problem, and yes, there is work being done to improve this, both on the IL2CPP side and on the emscripten side (the plan there is to move emscripten to being a native executable completely, as opposed to a collection of native, python and JavaScript code as it is now). This will get build times down, however, I would not expect build times to ever be as low as with the web player, as you will always need to actually build the player JavaScript.

    2. Let’s not be overly dramatic — in no way do 5-8 minute compile times make «any form of development impossible». Slower, more inconvenient, sure. But 5-8 minutes is pretty normal for mobile developers and always has been, and we’ve got along fine.

  16. Could you develop unity extension for chrome

    Chrome extension could do many things that WebGL lacks. Such as networking or accessing folder. I feel somehow you can making unity chrome extension as a center service and let the webGL exported from unity try to install this extension and call it for some functionality like socket

    Seem like Firefox able to do so, this would be a way to go over HTML and JS standard for a while

  17. Leave it to web browser developers like Google to remove features BEFORE a suitable replacement exists.

    This is yet another fantastic reason why the web should NEVER be considered a software platform. It’s a document platform that’s been hacked all to hell, end of story.

  18. well, webGL does sound great. but i never managed to compile a working build with it.
    always got java scripts error so i assume it’s just not ready yet…
    hope it will be before google pull the plug from NPAPI for good.

  19. Andrew Keplinger

    Май 28, 2015 в 3:50 пп

    Another useful article concerning WebGL would be helping with support for gzip compression on the files for a variety of server configurations. Each browser requires it’s own set of adjustments to get the exported compressed files to work, so having a rundown of each, with recommendations and caveats, for Apache, Node.js, and other common server configurations.
    It may not be possible to provide guidance for every configuration, it would be useful to know when running off virtual hosts and other locations.

    1. Yes please!!

  20. Unity should be working with browsers to stop blocking NPAPI instead. WebGL will never be as good as WebPlayer and it will be years before it’s even an acceptable solution.

    1. I can’t agree more.
      There’s no real reason for NPAPI deprecation except for Google forcing people to use their own Native Client (NaCL) API.

      1. No reason at all, except it’s an API created by Netscape in the 90s, with serious security holes. Many things in the web use it, which makes the entire internet a less secure place. Deprecating it and moving forward in favor of the new standard is the best option. It will need everyone to take some time to adapt to the new tech, but eventually it’s going to be better than the old stuff.

        1. But the problem is current standard are not cover enough things that NPAPI could do. Before moving forward the standard itself should ready to replace. Your argument is not wrong, but not now

        2. Maybe this is the time to deprecate NPAPI because this forces Unity and Unreal to work with the browser companies to improve WebGL ¿who can improve WebGL? Google, Mozilla and Microsoft, ¿who is forcing this? Google. Or maybe this is random and crappy desition, who knows.

        3. Jonas Echterhoff

          Май 29, 2015 в 9:34 дп

          I agree here — the decision to kill NPAPI with all it’s security issues is not a wrong one. The only thing unfortunate is the timing, as we are right now in a situation where we cannot provide an adequate replacement for the technology they killed. However, given current developments in this space, I am confident that in a year or two from now, WebGL will have matured so much, that Unity web content developers will be in a much better position then they ever have been with the web player.

        4. «They will polish WebGL and all will be good» — absolutely wrong! WebGL is based on JavaScript, yeah? Do they expect developers to rewrite their NPAPI plugins (written in their favorite language) to that stupid outdated JavaScript with so fundamental design flaws and dynamic typing? F**k you Google!