Unity Web Playerのロードマップについて

10月 8, 2015 : テクノロジー

2013年の終盤、GoogleはChromeブラウザーにおける (Unity Web Playerのような) NPAPIプラグインの非推奨化とサポート終了のプランを発表しました。さて、そして2015年9月になりましたが、GoogleはNPAPIプラグインサポートを削除した Chrome 45 をリリースしました。さらに、他のブラウザーベンダーもGoogleの決定に追従し始めています:マイクロソフトは新しいOSである Wndows 10 向けに新しいデフォルトブラウザーのEdgeを導入しましたが、このブラウザーもUnity Web Playerのようなプラグインのサポートを削除しています。本日、MozillaもFirefoxについてプラグインサポートの終了に関するプランを発表しました。

Webのエコシステムは明確にブラウザープラグインから遠ざかっていて、プラグインを使用したコンテンツを再生できるブラウザがなくなる日が急速に近づいています。この展望に対してUnityは別のWeb向け技術の開発にリソースを投入しており、さらにUnity Web Playerの終了にむけたプロセスを開始します。

本日、私たちは終了プロセスの最初のステップ、つまり Web Player を非推奨(deprecation)とすることを発表します。Unityが機能を非推奨(deprecated) にするということは、その機能の利用は控えた方がよく、また将来のUnityのリリースで削除されます、という意味です。Web Playerについては、Unity 5.2 および 5.3 についてはWeb Playerのコンテンツを引き続きビルド出来ますが、Unity 5.4 (2016年3月リリース予定) ではWeb Playerのサポートを含めない予定です。その後、Web Playerはサポート外の製品となります。

では、「2016年3月以降にUnityでWeb向けに開発したい」という人にとっては、これはどういう意味になるんでしょうか? 5.4では、Web向けのコンテンツを出力出来るオプションは、現在プレビュー版として配布されているWebGL出力機能のみになります。Web Playerと違い、WebGLはプラグインではなくブラウザの標準機能を使って動作します。これはつまり、WebGLのコンテンツはブラウザにプラグインのインストールが必要ないということです。ただし、WebGLはWeb Playerとはまるで違うプラットフォームで、Web Playerとは機能もパフォーマンスも差があるということを理解することが重要です。私たちは現在ブラウザーベンダー各社と密接に仕事をしており、このギャップができる限り小さくなるために努力していますが、それでもセキュリティ上の観点などからかけられたプラットフォーム上のいくつかの制約 – たとえば利用可能なネットワークプロトコル – などは残ります。

WebGLでの開発についてより詳しくは、Unityマニュアルの「WebGL での開発を始めるにあたって」をご覧下さい。

じゃあ、今ウェブ上にあるWeb Playerで作られたコンテンツはどうなるの?ユーザーはUnity Web Playerで作られたゲームを今後も遊べるんですか?

短い答えは「はい」です。Web Playerで作られたコンテンツはNPAPIプラグインをサポートするブラウザーで遊ぶことが出来ます。Unityは Unity 5.3をその後もダウンロード可能にします。Web Playerは現存するコンテンツについてはどれでもひきつづき実行する事が出来ます。
ただし、それにはNPAPIをサポートするブラウザーを利用するか、NPAPIサポートを打ち切る前の古いバージョンのブラウザーを使う必要があります。加えて、Web Player のビルドはメンテナンスを打ち切るので、私たちにはこれを利用することにはセキュリティ上の潜在的なリスクがあることをユーザーに周知する必要があります。UnityはWeb Playerで作られたゲームの重要性と歴史的関連性を非常に深く理解していて、いままでにWeb Playerで作られたゲーム達をまた再び遊べるようにしたいと強く思っています。私たちはこの件について社内にワーキンググループを作って、代替になる技術的解決策を調査していますので、進捗がありましたらまた皆さんと共有させていただきます。

コメント (97)

コメントの配信登録
  1. Christina

    12月 7, 2015 3:35 am / 

    As an average, everyday person who is ignorant of all the “techy” talk above, and just wants to play games (free flash player websites, i.e. like Kongregate)….could anyone reply in plain, dumbed down english lol, the answer to this question: if i have to update the unity plug in on firefox, how do i do that since Firefox has it labeled as “research” on the addons menu? PC specs: Windows 7 prof. Firefox current update. ….the few games i play that have the Unity icon, look beautiful but i still get images with purple color blotting out my weapons in a game and i don’t know if thats the webplayers fault or the person who made the game??

  2. Jacco

    11月 11, 2015 9:27 pm / 

    I am trying real hard to embrace WebGL but have one issue I don’t know how to handle. When I build my project I get a compressed version that is 26Mb in size and I get a release version that is over 200Mb in size and when serving it from my WordPress website I am not able to get it to serve the compressed version. I have used phpinfo() to check that compression is active then installed a plugin to force compression active then went and modified my htaccess file to force compression active and in all my attempts to load the compressed version I have failed and have to wait for a 200Mb download…

    I’ve ben instructed to stream my levels so the game loads faster but considering there is only 1 scene in this demo and this demo doesn’t do anything yet a 200Mb download seems super extreme to me. A 500 or 1G download every time you want to play is guaranteed to drive people away from my site… So how does one get the compressed version to serve?

    As I said before, I am trying to embrace WebGL but the immense file size per build is making it super hard to embrace…

    1. Jonas Echterhoff

      11月 11, 2015 9:44 pm / 

      How to get the server to host the compressed file is specific to the web server used, so we cannot provide generic instructions for that.

      However, in Unity 5.3 we will fall back to handling compression in JavaScript if the server is not set up correctly to serve the files compressed on the http level, which should remove the necessity of dealing with this.

  3. Alien Delounex

    11月 11, 2015 4:56 pm / 

    HTML5 is the bigest crap out there ever created. Google have pushed this crap this far to took over global advertisement market share.
    I am asking You for a minute to stop and think about who and what did in order to come to this.
    I start to believe that Mozilla does not anymore support the freedom of software, but it is influenced badly.

    1. Alien Delounex

      11月 11, 2015 5:01 pm / 

      I am asking for a revolt against this killing of liberty of the third party apps and plugins the way peoples love and prefer. Google and Mozilla is acting against the democracy !!!

      1. Matt

        11月 13, 2015 2:24 am / 

        You’re a fruitcake.

    2. Dread Knight

      11月 16, 2015 2:21 am / 

      Basically anyone can make WebGL apps as it’s native stuff, while you’re saying people should bother with 3rd party plugins (sometimes not even supported by the platform) in order to be able to check out content. Imagine a world where every website you visit requires you to install a certain plugin, wait, that already happened before…

  4. Mark Ripley

    10月 29, 2015 9:15 am / 

    Any ideas when webGL builds will work with mobile browsers? Currently works on neither iOS or Android.

    1. Japa

      11月 9, 2015 8:04 am / 

      The problem is that webGL in general is disabled by default on mobile chrome, though it can be enabled. Relying on that probably isn’t a good idea, though.

    2. Eric

      11月 12, 2015 12:43 am / 

      It’s not great, but I have an iPhone 6s Plus and build webgl, host on Dropbox and can run on my phone. I use touchscript for touch input. Work well enough for simple stuff.

      1. Jonas Echterhoff

        11月 13, 2015 9:08 am / 

        Yes – if you have a top-end phone, you will get decent results for simple Unity WebGL content. But the same cannot yet be said for the mass audience of “mobile internet users”.

  5. Bryan Thatcher

    10月 27, 2015 8:04 pm / 

    Wow, that soon? I left a similar comment in the initial blog post about the future of the webplayer. And I admit, I haven’t read all of the way down this one, but I know the deal. I suggested Unity create their own browser. This would not solve the problem of webplayer content not being accessible in whatever browser people are already using. But in would ensure all existing webplayer content and anything new would be available indefinitely. I am envisioning something like Steam for Unity webplayer content. Pro Users would be able to link directly to their content, free users would have to be in more of a community area. Someone would make money, and WebGL is a long way from being usable.

    I do real-time design visualization. I rely on the webplayer to keep my projects up to date. A client can just visit the site I set up and see where we’re at. They don’t need to re-download a standalone version and manage the files . And I don’t have to deal with outdated content floating around. Anyway, to that end I created my own browser. It’s just a windows form and a browser with a hard coded link, project specific. It’s written .NET so I’m sure it’s just a stripped down IE, and I don’t know if it will be affected by the plug-in mandate. There is a download URL below if anyone wants to check it out. The project has just been started, I’ve got about one day on it, but you’ll get the idea. The ZIP contains an EXE that functions like a viewer, it does not install anything.

    I just thought of this, but for that matter why doesn’t Unity write a browser that can support WebGL they way they need instead of blaming the browsers for not supporting it or whatever. They must have as many resources as anyone else in the game.

    https://virtualziggurat.sharefile.com/d-sbf39a5d20874482a

  6. JN

    10月 27, 2015 4:38 am / 

    What if our target group is still using IE 8 or below which didn’t support HTML5 and Webgl? For some reason our customer still using IE version below 8 (some of them even still using IE 6). And I don’t see a reason for them to update their browser version. Is there any support or plan to support those browser version? Or should I just stick on Unity 5.3 in order to build the webplayer version?

  7. Sha

    10月 22, 2015 5:22 am / 

    In the 2015 your 3d Game Engine don’t support right to left languages ! why ?

  8. OSMAR

    10月 21, 2015 9:02 pm / 

    oagr2006

  9. Zeblote

    10月 20, 2015 4:56 pm / 

    Why do webgl builds need to contain the engine every time, leading to huge downloads?

    Would it not make more sense to load the engine once from your CDN (just like the webplayer did it) and have builds only contain the actual project? If multiple projects use the same version this could also speed up downloads a lot as the engine can be loaded from browser cache.

    1. Jonas Echterhoff

      10月 20, 2015 5:01 pm / 

      This question was already answered further below on the comments section:

      “In WebGL, we don’t split out the engine code, because we want to allow stripping of unneeded engine parts, and because we allow publishing from patch releases. The possible combination of releases and stripping configurations are endless, so the chance of two pieces of content sharing the same are very low.

      We are researching some promising options for making builds smaller by sharing reusable parts between builds without requiring exact matches between content versions, but it is still too early to speculate where we might end up on that.”

  10. raptorx64

    10月 19, 2015 5:02 am / 

    “Normal” people do not trust the web player, I send links to web player demos to my normal average mac user dummy friends. They think it is a virus and resist installing it. So webGL ist the way to go for the future. Good decision.

    1. koblavi

      10月 20, 2015 3:02 pm / 

      I think we here all agree the WebGL IS the future. Question is, what to we do about the present?

      1. Bony Yousuf

        11月 2, 2015 5:41 pm / 

        You hit the nail with this

  11. Indy

    10月 17, 2015 4:21 pm / 

    Maybe solution like Java Web Start would be fine?
    https://www.java.com/en/download/faq/java_webstart.xml

    1. koblavi

      10月 19, 2015 5:57 am / 

      Same problem! It’s a plugin. Doesn’t even work in chrome anymore

      1. Indy

        10月 19, 2015 10:37 am / 

        I think it’s not connected with plugin, but is file’s extension (.jnlp) opened in external launcher.
        https://blogs.oracle.com/java-platform-group/entry/launching_web_start_applications

        So, clicking on link to .unity3d file in browser could start some Unity launcher, the same way like clicking on url to pdf starts PDF Reader application.

  12. Wim Wouters

    10月 16, 2015 11:14 am / 

    Back in 2002 I founded my company with one goal in mind: Conquer the world with ONLINE 3D GAMES!
    At the time there was only (mostly) Macromedia Director that could publish hardware accelerated 3D games in the browser, and it had a LOT of other very powerful features multi-user system, camera vision,…
    We build a website and about 40 small but fun 3D webgames. During our top days we had over 400.000 visitors playing our games.
    A few years later Unity joined the online playground and it seemed like the future of the web would be wonderfully filled with innovations developed by 3rd party plugins.
    Now we can’t make decent 3D games online anymore… with current WebGL we can not even do what we did back in 2002… WTF, that’s 13 years ago!!!
    In my opinion it has nothing to do with security… I believe it is all MONEY POLITICS… if we support plugins, people won’t go to our store and by our games. Also maybe some plugin developer might become big… We can’t have other big companies doing anything relevant.
    A decade ago I really believed that software as a service was going to be a really big thing… you browser would be able to do anything. Now it seems like you just have to download more software than ever. We just call them App’s, that sounds cooler. Oh, and you browser will only do what “THEY” want it to do. It’s not only plugins of course, next you will only be allowed to visit pre-approved websites.

    Sorry about the rant, but just don’t like the feeling that we’re loosing our online freedom too… sad.

    1. james flowerdew

      10月 16, 2015 1:31 pm / 

      Thank you for writing this. My thoughts exactly.

    2. Pete Roobol

      10月 16, 2015 1:36 pm / 

      Hi Wim, we echo your post entirely with a similar background ourselves through shockwave & unity development over the years.

      This is a major regression in terms of end user playback quality, WebGL is just not ready yet to stand up with the native powers.

      May these bleak times resolve soon…

    3. Wim Wouters

      10月 16, 2015 2:32 pm / 

      Wish I could edit my typos ;)

    4. CMaxo

      10月 20, 2015 4:57 pm / 

      What you’re writing is actually really close to what this is all about.

      The reason why each browsers’ companies decide to remove plugin support is ALL about money… To be precise, it’s to make add-on like Adsblock and “downloaders” that allows users to access some online content without visiting a website unavailable anymore. You would be surprised about how much some company are ready to pay to “force” each browsers developers to do such thing as remove NPAPI support. A plugin like Adsblock allows users to skip any video advertising on a website (or remove the advertising from appearing) as long as the advertising’s link is within the block list which can also be upgraded by the users themselves. The downloaders allows the users to download a music or a video and access it offline, which means the user doesn’t need to return on the webpage (with the ads) to access it anymore.

      Every years, many “popular” website owning companies are complaining that their ads revenues have been cut in 25-40% just from such plugins. The revenues of those websites, from ads, comes in the hundred of thousands per month, meaning they are crying around about loosing money “they could have owned”. The fact that many users of those plugin actually use them to protect themselves because many ads distributors (the servers hosting the ads images and videos) doesn’t have any security system for removing phishing script or virus (within the PhP of the ads) from their stored ads never even crossed their one-side-tracked mind.

      It has been proven already that the risk of security from any obsolete plugins in the browser are not even reaching 0.1% of the risks involved from online advertising… More than 80% of the virus caught online aren’t from illegal software/medias download nor obsolete plugins, but from websites’ advertising blocks.

      Talk about risk of security… <_<"

      1. Jonas Echterhoff

        10月 20, 2015 5:06 pm / 

        This all sounds very nice, except that NPAPI plugins never had *anything* to do with ad blocking whatsoever. Plugins to do ad blocking hook into the browser using different mechanisms, and nothing is changing about that.

    5. Adam L

      10月 21, 2015 9:57 pm / 

      Sadly I agree. I played with the web back in 97, made it a career in 98 and then fell in love with Flash in 99. Back then it was all magic by the time 2002 came around. Seemed like Flash and other plugins like Unity were going to allow anything you could dream to be reality (2D games were a blast to make in Flash). Lasted for a few years but around 2005 people started hating plugins and Flash and then in 2009 Steve Jobs killed it with his open letter. That was a dark period as you couldn’t do much on the front end of the web without crazy hacks and Flash couldn’t be used… html5 just within the last year or so has really reached a point where I feel like what was possible in Flash back in 2001 is possible again, mostly. But what a crazy step back the last several years have been. I even thought about getting out and moving on from web coding but html5 like I said actually feels like it has the right stuff now, er again. Some things like the situation with fonts is mind blowing in it’s craziness still compared to Flash but that’s about it other than no common API like Flash Pro (or Unity) and some advanced fx’s.

      As for the guy who said it’s about money. Yes! I don’t blame the plugins or ad blockers although they’re doing their best to kill the open web. I blame Apple and it’s creation of Apps. Jobs was a very smart guy when he pulled the trigger on that. Apple’s own private web that people or developers pay to get into the gated community. And the irony is it looks just like what plugin were supposed to be. You download the framework and the data flows through it. Only Apple gets 30% of the cash in their version… Genius! I’ve had discussions about this and it’s just amazing how so many people believe what Jobs wrote and that he did it to make the web better for nothing more than altruistic reasons.

      Anyways yay for html5 and webGL!!! Then again it feels like 2005 again…

      1. Adam L

        10月 21, 2015 10:16 pm / 

        I’d also like to add that Jquery, Moment, Bootstrap, Modinizer and other libraries (future Unity possibly) would be SO MUCH more useful if browsers had something like a Super Cache like concept. Something like a plugin but using standard Javascript / API’s that browser vendors push to clients. The browser would also know the library was already built in so no server call would even be needed. Seems like a wonderful idea to me and would be the best of both worlds. Open standards but you wouldn’t need to download libraries over and over again at run time.

  13. Dave Carlile

    10月 15, 2015 2:24 pm / 

    While I understand the loss of the Web Player is a blow to many, I see it ultimately as a positive. It motivates Unity to push forward with WebGL, and Unity is such a big player (it seems) that they can push browser vendors to get their act together and implement some sorely needed browser technologies. Browser games without plugins will be a net positive for developers. One step backward, five steps forward.

  14. Kamil

    10月 13, 2015 5:50 pm / 

    Can we expect Web Player support for 5.3.x minor releases as well?

    Our enterprise environment migrates / certifies to a new Web Player version at the end of a major patch cycle only. This is to ensure maximum stability and because certification is a very slow and frankly painful experience.

    As such, we would greatly benifit from the 5.3 feature sets but only once they are stabilised.

  15. dusho

    10月 12, 2015 8:20 pm / 

    That is quite a hit for all the web games and also game jams. Unity web player was rather popular platform to export game jam games to and also just to show people quickly what are you working on. Unity’s WebGL export is still unusable and browser ecosystem has to catch up as well.. Can’t believe there isn’t a way how to port existing Unity Web Player into something still usable in all or most of browsers even though as a temp solution, but with whole functionality web player had…

  16. Don

    10月 12, 2015 5:35 pm / 

    Jonas, it would have inspired a lot more confidence if you had provided an actual WebGL roadmap when announcing you were killing the web plugin. You keep pointing people at a forum post you made long ago and calling it a roadmap, but it has zero information we can use for planning our projects. What can we expect in 5.3? It doesn’t actually say, it just says what won’t be in 5.3. What’s due in 5.4? 5.5? No info. Is unity actually committing to usable WebGL in 5.5 or even 6? No info. That forum post isn’t a roadmap, it’s just you and unity saying “gosh this is hard” which after watching you working on it for 2+ years we already knew.

    As a long time unity user, all the way back to 2008, I remember the total disaster that was the “new unity GUI” first promised in what, Unity 2.0? And that we didn’t actually receive until something like Unity 4.6. The total lack of any specificity on what Unity is actually going to deliver and when it is going to deliver those things gives ZERO confidence that you have an ability to get past “gosh this is hard.”

    I love Unity, I’ve built my company on it, but I’ve also watched Unity absolutely fail catastrophically for YEARS to fail to deliver a major, critical upgrade like the “new Unity GUI” and the total lack of any real roadmap for WebGL shows all the signs of U.S. customers being stuck in the same “wait for five years for Unity to get its act together” mode with WebGL.

    Worse, the horrible state of the things around the core WebGL functionality make it clear that no one is seriously trying to use this tech. Have you tried putting a WebGL export on a CDN? No? Then you wouldn’t know that it’s impossible because the WebGL exporter bakes file paths into a custom JavaScript file it exports, and that file has procedurally generated memory data values that change with every export so you can’t just replace it with your own loader AND that file actually has three completely different and unrelated ways of finding and loading the three different types of files it loads (strongly suggesting you had three different interns working on it because no one programmer would write three such terrible and convoluted loaders when they could have just reused the one terrible and convoluted loader they’d already written).

    Please keep in mind I’m writing this as a HUGE unity fanboy. I’ve built my company around Unity. I’ve been coding in Unity since 2008. I’ve convinced many others to use Unity. And I’ve watched WebGL walk down the same path of over promise and under deliver that the “new GUI” tried to sell us for more than five years.

    Please. Put together an actual roadmap for WebGL. Include things on it like “WebGL data files can be served from a CDN.” Publish it with the actual Unity road maps. We know WebGL is hard. We get it. That’s not a roadmap. A roadmap is “our customers will be able to do X when we ship version Y on date Z.”

    It would have been best if you could have done that as part of announcing you were killing the web plugin. You missed that chance. Please, don’t wait any longer. You customers have been waiting literally years for information on what is coming in WebGL and when. Right now, given that you’ve said nothing concrete, the best guess I can make is “it won’t be usable in March and I hope it’ll be usable by the summer but I doubt it.”

    And that’s a Unity fanboy talking.

    1. Jonas Echterhoff

      10月 12, 2015 9:39 pm / 

      The problem with giving release dates for most of the things mentioned in the roadmap blog post is that most of the things I talk about there are actually about developing browser technologies making things possible. While it is our job to integrate those technologies, we still require the browsers to actually ship support – which is outside of our control. We would not give you a specific release for a version, unless we have reasonably certainty of hitting that release (which we learned the hard way with new UI, as you pointed out). But there is no way in life we can give release dates for third party products with reasonable certainty. Once we have browser support and are actually getting ready to ship an implementation of a feature, things will show up on https://unity3d.com/unity/roadmap.

      >Have you tried putting a WebGL export on a CDN? No? Then you wouldn’t know that it’s impossible..

      All our demo content is hosted on our Akamai CDN.

      The loading of data and mem files is automatically generated by the emscripten compiler. The issue you have with it may be valid, and may be something we can either fix ourselves or talk to Mozilla about. But a blog post about the Unity Web Player is not the right place to report issues with emscripten. Please file a bug if you haven’t done so already, and quote the case number here for reference – then we can look into it.

  17. Derrick

    10月 11, 2015 2:08 pm / 

    I’m glad you knew this was coming, and started work on the WebGL plugin… However, you should’ve thrown more resources into this at least 2 years ago…

    1. Jonas Echterhoff

      10月 11, 2015 10:08 pm / 

      We did in fact start work on this 3.5 years ago. I honestly don’t think that the current status of Unity on WebGL is largely a matter of resources on our end. I think the browser ecosystem just has to keep up in some areas. And it is moving into the right direction. See this forum post for more details: http://forum.unity3d.com/threads/webgl-roadmap.334408/

  18. Ugur

    10月 11, 2015 5:12 am / 

    It’s sad specifically that the unity plugin gets deprecated and then at some point in 2016 not supported at all anymore.
    That said, i totally understand your decision, basically the browser makers leave you and us pretty much no other choice.
    It would have been nice, at least for the interim, if unity support could have been included in the browser like it is the case for flash right now. So updated via the browser, too.

    Me personally, i’m not affected much by this, i deploy to other platforms way more these days, it is just sad to me to have one option taken away.

    It is more sad to me when i think about many others and me got their start in making games and releasing them to the public using flash and then later as available unity via the web.

    What is most sad to me is to see that overall mankind is still very much on the level of following some “leaders” blindly and doing a witch hunt like crazy without really having a clue at all whether the paroles they yell are even true.

    This applies in many other topics, in this case also in the technology sphere and regarding plugins,webgl, html 5 etc again very clearly visible.

    The death of flash was proclaimed and the witch hunt summoned by Jobs and subsequently pushed to the extreme where it was made to seem cool when talking against any plugins and praise html 5 and webgl like the next big thing, so much more modern, more secure, just better, you know.

    So many of those moaning about flash made their comps slow have no clue that all the js ads replacing the flash ads are in many cases even worse.

    So many of them have no clue that instead of a flash file which could compress high color range jpg and png and vector graphics to nice small filesize, now instead we’re back to archaic levels of 256 colors max at large filesizes gif animations or video as the only viable alternatives for web animations.
    All these years later there is still no good alternative to flash for vector graphics animations published to the masses either.

    Even now, today, i read an Endgadget article linking to this blog post, and they talk about for many old unity made for plugin games a “hd upgrade” (to webgl) wouldn’t be possible.

    Haha, see, a “tech site” having so few clue that they think it would be an upgrade to deploy to webgl instead of the unity plugin.
    (Maybe in a few years, definitively not right now, the same content when deployed to webgl instead of to the unity plugin either doesn’t run at all, or way worse, sucks up more machine resources and is much larger in filesize, while having lots of unity functionality stripped away. And i’m not pointing this out to blame Unity, i know you are doing the very best possible within the given restrictions of the webgl/browser environment, i just point it out to make those limitations of the browsers/webgl clear. Maybe that should have done by way more people way earlier..)

    When tech sites are so uninformed, how can one expect more from the general public.

    Now, again, i don’t actually care that much bout deploying to browsers anymore these days, cause why? Cause as devs we’re now forced to deploy to other platforms..

    So yeah, i’ll stop thinking about that now, makes me depressed =)

    Sheep yelling pro “open web” paroles while not understanding the sad irony that they are supporting killing off more and more options for people to express themselves so creatives are forced more than ever before to publish to closed platforms controlled by single entities..

    1. Jonas Echterhoff

      10月 11, 2015 1:35 pm / 

      I disagree.

      Yes, it would have been easier on us and, more importantly, on our users, if Google (and the others who followed) would have allowed more time for replacement technologies to mature. I do think the timing here might have been premature, and I’ll admit that the current transition is anything but smooth.

      But: Ultimately, killing plugins is the right decision. Plugins have become a security liability, and the cause for many exploits in recent years. Plus, as developers, you really don’t want the situation where a single entity holds the key to publishing content to a platform as universal as the web. That has gone bad in the past (remember Adobe suddenly asking for 9% of all revenue made with 3D Flash content?), and would go bad again in the future.

      1. Ugur

        10月 11, 2015 8:16 pm / 

        @Jonas: I agree on the downsides of plugins.
        As a rule of thumb i would also agree that it’s better when the keys to everything are not in one entities hands.
        On the other side, in reality, handing them out to several instead only works out if the several entities one gives the keys to instead are actually pushing properly and also in the interests of users and with full force and in well united and organised way.
        Seeing how slowly adoption of new technologies is pushed forward on browsers and how inconsistent to this day, i’m not that convinced of that in this case.
        And when looking at how things evolved, i’m not convinced it was for the better all around so far.
        -gif anims instead of png/jpg/vector flash anims: reduced color amount, worse look, bigger filesize for worse content.
        -html5/webgl: not as progressed as unity plugin or even just as flash on many ends, much less reliable regarding which browsers support what. Overall slow progress on browser creators side to push it forward at full force to achieve performance and capability levels of plugins like unity anytime soon.

        Web games market for html5/webgl games: besides for advertising games a complete niche thing, and no immediate outlook for getting better.
        Compared to the vibrant community around flash animations and games which spurred many thousands of creatives making it big later on other platforms, yeah, pretty dead nowadays.

        So overall a very strong push for game/app developers (since few other money making options on the web for such content) to distribute their content on app stores, which are owned by a single entitity way more than the open web was, no matter if one distributed to it via a plugin or not.
        So then not your content is made by a tool with keys given to one entity, instead your whole distribution channel and audience is tied to one store/platform.

        Regarding your example with Adobe doing bad things with the keys: in general i totally agree, Flash went massively downwards as soon as Adobe bought it and that decision to charge was stupid and vein, but on the other side they were forced to such nonsense because of the attacks on the platform and money making ways via selling the tools for the platform so kinda moot to argue against Adobe on that one when it was the others forcing them to it =)
        (One could of course say maybe the whole thing would not happened to flash (and then other plugins) if Adobe hadn’t owned flash, since really, Jobs main issue was to have a pay back to Adobe, flash was just a good attack vector, but yeah, what does it matter now =) )

        Anyway, overall, yeah, i feel like we just have to accept the situation and yeah, maybe in 1-3 years it could look better, with browsers adopting new options for webgl and other things which allow content at better performance, ideally getting very close to what the unity plugin allowed, still, i feel like what was done there as political play to kill off some options while there was and still is no adequate replacement other than until there is forcing all to distribute to walled garden app stores, yeah, was not cool by the browser/platform holders.

  19. JON

    10月 10, 2015 7:12 am / 

    2 years’ project to develop a really sad to hear this news in the publishing process. Unity for the removal of mağduruyet should bring Flash support again. Our 2-year project would have to go to waste.

  20. Walter

    10月 10, 2015 1:39 am / 

    This is actually disappointing to hear. While we have already incorporated WebGL as one of our officially supported platforms, we still use the webplayer to support “legacy clients” (schools, governmental agencies, etc.) that are forced to use Internet Explorer. Now we will be stuck on 5.3 forever (or at least maintain a “5.3 version” of every application we do; if that’s even feasible). I think it’s still fair to say there are many situations where WebGL is not a possible option. This is not a criticism of the WebGL export (we like it a lot), but it’s impossible for us to rely solely on it.

  21. Thrawn75

    10月 10, 2015 12:20 am / 

    So… why not fork Chromium and make one stable/performant browser optimised for gaming on the web, including compatibility with current web plugin?

    Today’s games requires you to install Steam, Origin, … whatever bootstrapper, which does nothing but controlling licensing and customization. Why not jump outside of the current browser fences and link your web plugin to a custom protocol (i.e.: unity://gamex..) which will run locally instead of inside the browser?

    1. Jonas Echterhoff

      10月 10, 2015 11:09 pm / 

      Such a setup might make sense for the idea of preserving existing Web Player content, which we are looking into.

      But, as a solution to deploy new content, I don’t see it. It would have all the downsides of a plugin (namely, having an application to install), minus the actual integration with the Web. At that point, why wouldn’t people just download a Standalone instead?

      1. graspee

        10月 12, 2015 7:19 am / 

        With the unity web player users only have to trust one application, and one from a major, trustworthy company; they can then run as many games as they want and not have to worry about security. On the other hand, downloading standalone games they have to trust each one they download, often from people they have never heard of.

        This situation first became really apparent when I was looking at 7DRLs (7 day roguelikes). Suddenly, standalone exes looked suspicious and I breathed a sigh of relief every time I found a unity game.

  22. vulgerstal

    10月 9, 2015 8:36 pm / 

    Mozilla Firefox is the mainstream browser that is going to drop NPAPI by the end of 2016 . . .
    What is the sense to drop Web Player for Unity in March 2016?
    Maybe You should leave an option to install it, but mention that You, Unity Technologies do not take any responsibility for any issues with Web Player? Legacy obsolete plugin or something like that . . .
    For those who have trouble building WebGL on 32 bits OS . . . Have You heard of Virtual Machine App?

    1. Jonas Echterhoff

      10月 9, 2015 8:49 pm / 

      Mozilla actually plans to phase out NPAPI support and finish at the end of 2016. Some platforms like Windows 64-bit Firefox will be affected much sooner.

      But more importantly, what is the value of Unity keeping plugin support as long as the last browser drops it? Google and MS have already dropped support, meaning that less then 50% (depending on who’s stats you trust) of today’s browsers can still play back Web Player content, and that number is dropping steeply. Will such a declining platform stay viable for targeting new projects? Existing projects can still stay with Unity 5.3 and won’t be affected.

      The R&D cost of keeping plugin support, on the other hand, is very high, as the web player has complex backwards compatibility requirements, which often prevent us from doing refactors and improving our code. That, plus the security requirements for our engine code base mean that a lot of resources are needed to keep supporting this platform.

      1. vulgerstal

        10月 10, 2015 9:00 pm / 

        Yes, You’re right. Now I see how mainstream browsers establish a dictatorship . . .
        Anyway, thanks for Your work at Unity. Web Player support will always be in my heart.

  23. Paul

    10月 9, 2015 7:26 pm / 

    NOOOOO!!!

    My game does heavy math on background threads. It will not work on WebGL.

    1. Aras Pranckevičius

      10月 10, 2015 8:01 am / 

      Browsers are working on making both threading & SIMD math possible. That is not out just yet, but hopefully soon(ish) it would be possible to do all that.

  24. Jack

    10月 9, 2015 5:36 pm / 

    Oh! Is Unity filing bug reports with Microsoft everytime Edge crashes in Windows 10 when Unity is testing WebGL?

  25. Maksims Mihejevs

    10月 9, 2015 3:28 pm / 

    Does Unity Team considers to have modular approach to what goes into compiled engine for WebGL target?
    Many projects simply not using a lot of features, so related functionality can be dropped of the compiled engine.
    This of course complicates a lot in terms of technical architecture, or simply not possible with current engine design. Engine it self is a bit over complicated for simple web based experiences.
    But does Unity Team considered that option?

    Another question, if WebGL target will get another way of getting assets into a project, not bundle files that have everything. But streaming solution, that would load what is required for the game, and does take platform support in account. Like PVRT textures for iOS, and different audio formats for different browsers / platforms?
    This will add a caching benefits to games as well, and will increase loading times when revisiting game, as well will remove a need to store whole bundle in-memory. And will allow to patch games easier, still benefiting browser cache, that will eventually reduce content delivery costs, and benefit from browsers streaming nature.
    What you guys think on that field?

    1. Jonas Echterhoff

      10月 9, 2015 3:38 pm / 

      >But does Unity Team considered that option?

      Not only considered this an option, this is what we are doing today. That is why an empty project today will “only” emit 2.5 MB of JavaScript code, as opposed to 6MB or so, you might need for more fully featured projects. Subsystems like Physics, Animation, Audio, etc will all be stripped from the build if not used.

      Now, we have this today, but that does not mean that we won’t work on getting better at this. We are stripping a lot of major subsystems, but there is still a lot of code in the “Core” which is always included – more then you should always need, so there is more work to be done. In the shorter term, one thing I want to fix is to allow developers to actually make informed decisions on stripping – by showing a report of which modules are being included in the build and why, and how much code they generate. As stripping right now is pretty much a black box which will make your build smaller, but where you have very little understanding or control over what is going on.

      And as for your asset streaming option, AssetBundles should be able to handle that case today.

  26. AntiDanilevski

    10月 9, 2015 8:33 am / 

    Good news, actually. Deprecating WebPlayer means that Unity team will have WAY more resources for developing and bugfixing WebGL building. Actually, there are only two things that stops us from moving to WebGL version:

    1. No debug possibility. This is the MAJOR problem of WebGL builds at the moment: something crashes and you have no way to find where it crashed. So, imho, main priority should be a solid WebGL debugger for Unity editor.

    2. No multithhreading, though we expect it in 5.3? Because now, when we are loading an asset bundles and unpacking it in a single thread with the game, it freezes for about 1-2 minutes (!). This is a blocker for our development.

    I don’t know if my imput here will have use, but when those things are fixed, I can promise that we’ll deliver Unity game to tens of millions of users worldwide.

    1. Stefan Schubert

      10月 9, 2015 11:13 am / 

      1) We have some ideas about how to improve debugging but nothing to talk about yet.

      2) Support for multi-threading is not coming in 5.3 since there isn’t a single stable browser out there that’ll support it in the 5.3 time-frame.

      1. Jonas Echterhoff

        10月 9, 2015 11:20 am / 

        To elaborate, both threading and debugging support are on our radar, but both require developments on the browser side before we can move forward with either of them, which is why you won’t see any changes for these two items in 5.3, and there is not much we can do to accelerate that.

        1. AntiDanilevski

          10月 9, 2015 12:37 pm / 

          Hello Stefan and Jonas!

          Thank you both for the lightning-speed and detailed answers. Though news are really really bad for us. Perhaps there is a workaround to solve client freezing while bundle loading in one thread?

        2. Jonas Echterhoff

          10月 9, 2015 12:58 pm / 

          @ANTIDANILEVSKI: Really smooth background loading of AssetBundles does indeed require threading support. But 1-2 minutes of freezing is unexpected and does sound like something is wrong (unless your AssetBundles are really really huge). Maybe you could send us a bug report with a repro case (and post the case number here for us to check), and we could take a look at what may be wrong?

        3. AntiDanilevski

          10月 9, 2015 1:29 pm / 

          Sure, Jonas, we’ll see what can be done and if special project can be prepared. Mind if I’ll contact you via e-mail and send it to you directly, to make it quicker?

        4. Jonas Echterhoff

          10月 9, 2015 1:34 pm / 

          Please do file a bug, because otherwise I will lose track of it. Once you have done that, you can send my the case number by email, though, to get my attention on to it.

        5. AntiDanilevski

          10月 9, 2015 1:40 pm / 

          Mind sending me your contacts to anti.danilevski at gmail.com? Because we’ll likely have to attach the whole project to the bug, and keep it updated somehow (or just create account for you so you’ll be able to upload it and update).

  27. Fernando

    10月 9, 2015 6:25 am / 

    The problem with the loading time in WebGL is not the 2.5MB of an empty project, the problem is that uncompressing and parsing all the JS code contained in that 2.5MB takes a long time.
    Is Unity working in the Web Assembly project? Because I think it’s an open project. That seems promising.

    1. Stefan Schubert

      10月 9, 2015 9:31 am / 

      Yes we are working directly with the browser vendors on this.

      See http://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-feature-roadmap/

  28. Adam Frisby

    10月 9, 2015 4:28 am / 

    I’m a bit concerned about the stability & functionality of the WebGL builds – we’ve been testing them on a large project that was originally designed for the Webplayer for the last 6 months, and while we have been able to get the project to work – there is serious and significant tradeoffs in functionality, appearance and stability.

    The last point – stability is a particular concern. Error handling in WebGL is not graceful – it seems it takes only the shallowest of bug to halt all playback entirely. Debugging is a exercise in futility and hair pulling – littering the code with Debug.Log’s is far more reliable than the stack traces. I am skeptical that by March these issues will be resolved.

    How about waiting for WebAssembly to become available in popular browsers, before depreciating the Webplayer?

    1. Stefan Schubert

      10月 9, 2015 9:36 am / 

      You can still use the Web Player with older Unity versions and publish your content that way. As written the plugin and the runtimes will stay online for people to use if they wish to.

      The webplayer might be phased out sooner by the browser vendors then WebAssembly is implemented. Sadly we can’t make this decision just by ourselves since we operate in the browser environment.

      1. Omer

        10月 9, 2015 3:43 pm / 

        This plugin blocking thing ruined everything. It put the last nail on facebook-unity games. Funny thing is, good old flash plugin still works despite the fact that everyone was so sure that Flash was going to die…

        1. Jonas Echterhoff

          10月 9, 2015 3:50 pm / 

          And Flash *is* going to die. It will just take some more time for Flash content to be less prevalent on the web so that browser vendors will be able to go ahead and pull the plug on that as well. They surely want to.

  29. Nate

    10月 9, 2015 3:28 am / 

    I’m really excited about this. It is gonna suck optimizing webgl and getting it right but in the end it’s definitely going to be worth it. As a developer I am fully willing to go through some pain for the payoff later. I really hope Safari ups its webgl game.

  30. LimboSlam

    10月 9, 2015 3:09 am / 

    Hi there! :)

    I just heard this news on the Pale Moon forums, and I would greatly like to know once the “End of Life” has officially come to Unity’s Web Player, will Pale Moon (an Open Source web browser forked off from the Firefox/Mozilla code) be able to play Unity’s content on gaming sites, such as nick.com, silvergames.com, ninjakiwi.com and cartoonnetwork.com that still uses your NPAPI Plugin; any browser still supporting this type of technology? I’m really concerned as I tutor Special ED students and use these games as part of a reward system, you know for staying on task and giving the effort to finish their school work and all.

    And as for Pale Moon, they do not follow MozCo’s direction anymore and so they will keep support for any NPAPI Plugin regardless of MozCo’s decisions on what Firefox does nowadays.

    1. Jonas Echterhoff

      10月 9, 2015 9:35 am / 

      As this blog post states, browsers which continue to support NPAPI will continue to be able to play existing Unity Web Player content. However, as the share of those browsers steeply drops, we will no longer continue developing the Web Player, and after Unity 5.3, Unity developers will no longer be able to deploy Web Player content with new versions of Unity (they will still be able to do so if they stay on 5.3).

      1. LimboSlam

        10月 9, 2015 6:29 pm / 

        Thanks for the response! :)

        And I know, I’m sorry about that. This news just really got me worried pissed me off as these plugins are part of my work environment; it’s my job and moral duty to get these kids through high school and prepare them for everyday life.

  31. Alexander Blanco

    10月 9, 2015 12:55 am / 

    I know you cant control what web browser companies do but I am hoping to deploy games to the web. I was hoping for a webgl roadmap. I still trust that unity will get their webgl up to speed in a way that considers long term issues. I just hope we will see it come out of its preview cycle in a reasonable time frame. The web is the biggest platform in the world and I want develop for it.

    1. Jonas Echterhoff

      10月 9, 2015 9:32 am / 

      Check out our WebGL Roadmap post here: http://forum.unity3d.com/threads/webgl-roadmap.334408/

  32. JP

    10月 8, 2015 9:59 pm / 

    Really, really pleased that preservation of existing web player games is something Unity is thinking about. I’m sure there are serious technical challenges but it’s the Right Thing.
    Bonus points if this somehow means web player games become playable on Linux! (even with Wine it would be a step up)

  33. Onsterion

    10月 8, 2015 9:09 pm / 

    More devs working for do better Unity WebGL it’s a very good notice.

  34. DimensionU

    10月 8, 2015 9:03 pm / 

    Sounds to me like FPS style games are no longer going to be realistic in the browser. Web sockets (the only thing that can work with WebGL ATM) are TCP based. FPS games rely heavily on UDP.

    1. Jonas Echterhoff

      10月 8, 2015 9:12 pm / 

      Another option here would be WebRTC, which allows UDP-style peer-to-peer connections between web clients – unfortunately, that rules out Safari, as Safari does not yet support WebRTC.

  35. FMAESTRE

    10月 8, 2015 7:56 pm / 

    Hi,

    Why don’t you work on a secure / store/ streaming service so native build would be digitally signed and deployed .

    Clients’ application package would be able to be downloaded / cached and launched.

    1. TMPxyz

      10月 9, 2015 3:35 pm / 

      Yeah, I agree with that idea.

      A small executable which would startup when click a link in browser, and automatically download and play webplayer.

      That would be a better solution than WebGL for now.

      1. Jonas Echterhoff

        10月 9, 2015 3:49 pm / 

        Such a setup might make sense for the idea of preserving existing Web Player content, which we are looking into.

        But, as a solution to deploy new content, I don’t see it. It would have all the downsides of a plugin (namely, having an application to install), minus the actual integration with the Web. At that point, why wouldn’t people just download a Standalone instead?

  36. Bony Yousuf

    10月 8, 2015 6:20 pm / 

    Wrong move made by Chrome and now followed up by Mozilla. They should not disabled NPAPI plugin so soon without even making sure that their browser can handle WebGL technology properly. How are users supposed to play web based game now? WebGL is a horrible experience. It cannot run anywhere near that of UnityWebPlayer when it comes to performance.

    Maybe Unity should rethink about their flash player option?

    1. Link_of_Hyrule

      10月 8, 2015 6:42 pm / 

      Flash is a dieing plugin and we don’t need one more thing to keep it alive. The NPAPI has been around since Netscape Navigator! Hence why it’s called the Netscape Plugin API. It came out in 1995! (https://en.wikipedia.org/wiki/NPAPI)

      This is why there are so many bugs and security problems with plugins that use it. It was the correct decision for everyone to drop support for it and force vendors to make new plugins using more powerful, modern, and secure APIs. There are a lot of newer solutions to the problem and I’m sure they’ll resolve it. A solution for Chrome Specifically would be to utilize the pepper API similar to how the built flash does. However I’m not sure if FireFox or Microsoft Edge has the pepper API or if it’s just Chrome Specific.

      1. Jonas Echterhoff

        10月 8, 2015 8:02 pm / 

        PPAPI (Pepper) is Chrome only, and shares most of the security issues NPAPI has. Google does not encourage other vendors to write PPAPI plugins, and I don’t expect that they will keep that path open for longer then they have to (ie, as they will need to support Flash).

        WebGL + asm.js (and in the future WebAssembly) is the right technology to drive this in the future, and it is making good progress in the right direction. It will be some time before you can get an experience comparable to what the web player was, but already today, the benefit of not having a plugin install barrier which may result in 80% user drop off, may make up for that.

  37. Lee

    10月 8, 2015 6:15 pm / 

    This would only be relevant to Chrome, obviously, but has leveraging Native Client in some way been explored? https://developer.chrome.com/native-client

    1. Link_of_Hyrule

      10月 8, 2015 6:32 pm / 

      They used to support Native Client but they dropped it probably because not enough people were using it sadly. Honestly I think they should have kept Native Client support but maybe they can use the pepper API on Chrome since the NPAPI is going bye bye.

  38. NEO

    10月 8, 2015 4:34 pm / 

    But why do we need 64 bit computer to buid a webgl project? Is there any specific limitation in 32 bit Computers that one can’t actually build webgl there?

    Thanks

    1. Stefan Schubert

      10月 8, 2015 5:01 pm / 

      Parts of the tool and compiler chain to build WebGL are not available as 32bit versions and thus we can’t offer it in the 32bit Editor.

  39. Stefan

    10月 8, 2015 3:55 pm / 

    An empty scene in 5.3 results in a 2.5MB build so we made some big progress.

    The confusion with the different folders in the output leave a wrong impression about the actual size of the builds. Not all of them are needed, only the Release part.

    1. Chris

      10月 8, 2015 6:13 pm / 

      To be clear, an empty WebGL build is 2.5 MB? You don’t explain what platform builds to that size.

      1. Aras Pranckevičius

        10月 8, 2015 7:14 pm / 

        Empty project built to WebGL out of Unity (with code stripping & compression on) is 2.5MB. Not ideal, but not terribad either; and we’re working on improving the size.

  40. Imi

    10月 8, 2015 3:43 pm / 

    I am mostly concerned about the download size.

    Small web-player games used to be around 800k to 1 MB (which is already outrageous terrible big).

    Last time I checked, an empty WebGL game was around 80MB download.

    1. Rob

      10月 8, 2015 3:48 pm / 

      You have to understand what’s going on.
      With the player, the platform and Unity APIs are all contained in the plugin. So that game can just deliver mostly gameplay code.
      With WebGL the game deliverable has to include the entire unity stack, that’s required, not just the gameplay.

      1. Imi

        10月 8, 2015 4:29 pm / 

        Exactly.

        Why can’t different WebGL-games all built with Unity share the Unity-part? Will that be ever possible again?

        1. Jonas Echterhoff

          10月 8, 2015 8:08 pm / 

          Note that even with the Web Player, it would frequently have to download new Unity Engine versions to run specific content, which would be a 10MB download every time.

          In WebGL, we don’t split out the engine code, because we want to allow stripping of unneeded engine parts, and because we allow publishing from patch releases. The possible combination of releases and stripping configurations are endless, so the chance of two pieces of content sharing the same are very low.

          We are researching some promising options for making builds smaller by sharing reusable parts between builds without requiring exact matches between content versions, but it is still too early to speculate where we might end up on that.

        2. Joel

          10月 8, 2015 8:50 pm / 

          I wonder too about not just having some code be shared, but also using a CDN to have the engine and asm.js do the delivery. Hopefully this would result in a browser cache hit rather than a network hit in the same way that jQuery is cached. Most browsers already have jQuery cached because so many websites references Google or one of the other big CDN’s hosting jQuery.

    2. Stefan Schubert

      10月 8, 2015 4:00 pm / 

      See my comment above about buildsize.

コメント受付を終了しました。