Search Unity

In late 2013, Google announced a plan to deprecate support for NPAPI plugins (such as our Unity Web Player) in its Chrome browser. Now, it is September 2015, and Google has released Chrome 45 with NPAPI plugin support removed. Also, other browser vendors have started matching Google’s decision: Microsoft is shipping its new Windows 10 operating system with the new default browser, Edge, which has removed support for plugins like the Unity Web Player. Today, Mozilla has announced a plan to phase out plugin support in Firefox.

Clearly, the web ecosystem is moving away from browser plugins and we are quickly approaching the point where no current browsers will still be able to run plugin content. Given this outlook, Unity is diverting resources into alternative web technologies and will begin the end-of-life process of the Unity Web Player plugin.

Today we are announcing the first step in that end-of-life process, the deprecation of the Web Player. When Unity marks a feature as deprecated it means that the use of the feature is no longer recommended and that the feature will be removed in a future release.  For the Web Player, Unity 5.2 and 5.3 will still be able to publish Web Player content, but Unity 5.4 (to be released in March 2016) will no longer ship with Web Player support. The Web Player will then become an unsupported product.

So, what does this mean if you want to target the web with Unity from March 2016 onwards? With 5.4, the only option to generate web content in Unity is our WebGL export, which is currently in preview. Unlike the Web Player, WebGL is not a plugin, but uses standard APIs exposed by the browser. This means that WebGL content runs without requiring any plugin install. However, it is important to understand that WebGL is a different platform from the Web Player and does not match the feature set or performance of the Web Player. We are working closely with browser vendors to make sure this gap becomes as narrow as possible, but there are some limitations which are defined by the platform – such as restrictions on the networking protocols you can use, which are mandated by security concerns.

Learn more about WebGL support in Unity in our documentation.

So, what about all the existing Web Player content that exists on the web, can users still play my Unity Web Player powered games?

The short answer is yes, all Web Player content will still be playable in browsers that support NPAPI plugins. Unity will still allow downloading of the Unity 5.3 Web Player to run any existing content. Note that it will be necessary to use either a browser which still supports NPAPI or on older version of a browser released before NPAPI support was dropped. Additionally, Web Player builds will no longer be maintained so it will be necessary for us to make end users aware of the potential security risks. Unity deeply understands the importance and historical relevance of Web Player powered games and keeping this back catalogue of games playable is something we care about. We have formed a working group to investigate alternative technical solutions and will update the community as we progress.

97 코멘트

코멘트 구독

코멘트를 달 수 없습니다.

  1. 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. 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 오후

      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. 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. 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. You’re a fruitcake.

    2. 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. Any ideas when webGL builds will work with mobile browsers? Currently works on neither iOS or Android.

    1. 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. 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 오전

        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. 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.

  6. 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. In the 2015 your 3d Game Engine don’t support right to left languages ! why ?

  8. 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 오후

      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.”

  9. “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. I think we here all agree the WebGL IS the future. Question is, what to we do about the present?

      1. You hit the nail with this

  10. Maybe solution like Java Web Start would be fine?

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

      1. I think it’s not connected with plugin, but is file’s extension (.jnlp) opened in external launcher.

        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.

  11. 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 오후

      Thank you for writing this. My thoughts exactly.

    2. 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. Wish I could edit my typos ;)

    4. 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 오후

        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. 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. 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.

  12. 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.

  13. 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.

  14. 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…

  15. 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 오후

      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

      >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.

  16. 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 오후

      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:

  17. 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 오후

      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. @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.

  18. 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.

  19. 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.

  20. 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 오후

      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. 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.

  21. 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 오후

      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. 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.

  22. NOOOOO!!!

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

    1. Aras Pranckevičius

      10월 10, 2015 8:01 오전

      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.

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

  24. Maksims Mihejevs

    10월 9, 2015 3:28 오후

    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 오후

      >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.

  25. AntiDanilevski

    10월 9, 2015 8:33 오전

    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 오전

      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 오전

        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. 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 오후

          @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 오후

          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 오후

          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 오후

          Mind sending me your contacts to anti.danilevski at 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).

  26. 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 오전

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


  27. 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 오전

      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. 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 오후

          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.

  28. 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.

  29. 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,, and 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 오전

      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. 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.

  30. Alexander Blanco

    10월 9, 2015 12:55 오전

    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 오전

      Check out our WebGL Roadmap post here:

  31. 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)

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

  33. 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 오후

      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.

  34. 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. 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 오후

        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?

  35. 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 오후

      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! (

      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 오후

        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.

  36. This would only be relevant to Chrome, obviously, but has leveraging Native Client in some way been explored?

    1. Link_of_Hyrule

      10월 8, 2015 6:32 오후

      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.

  37. 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?


    1. Stefan Schubert

      10월 8, 2015 5:01 오후

      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.

  38. 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. 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 오후

        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.

  39. 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. 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. 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 오후

          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. 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 오후

      See my comment above about buildsize.