Chrome to stop NPAPI plugins this month any news on WebGL 2.0?

Sure... but then you're just pre-compressing some of the easier-to-compress parts...

 

Not necessarily. If I have a Unity web game, it is most likely 3D which narrows the market somewhat to serious gamers. (As an example lets think of say a 3D shooter). Serious gamers are more likely to have all ready installed the Unity plugin. (Since they would have played other 3D games on the internet).

So I launch my new game targeted mostly at people who play games on the internet which corresponds closely with those who have Unity plugin installed.

Time to try out my new game with Unity plugin all ready installed: 10 seconds.
Time to try out my new game with WebGL: 90 seconds.

Percent of people who give up after 15 second loading time: 90%

Number of new players who like playing games on the internet, don't mind 90 second loading times, but refuse to use plugins : 0

So as you can see from these numbers I pulled out of the air, with the new WebGL, I will get 90% fewer players.

I think WebGL is a non-starter. Takes too long to compile, too long to load and too easy to decompile.Bring back OnLive streaming of games. Now that was a good idea. I played both Batman games and BioShock through that service which I never would have done otherwise. Unity should have bought out OnLive when it went bust.

 

Bandwidth, in my opinion, is more of a limitation than actual download time because you only have to download the game once, assuming you don't clear your browser's cache, but you need to continuously stream with OnLive.

OnLive may have worked for cities, but rural areas tend to rely on satellite and cell tower connections which have very strict bandwidth limits. Verizon's data plan, at least in Virginia, only gives you ~5GB per month.

Not to mention OnLive required low latency due to having the game running on the server. Satellite has a huge latency that makes it practically worthless for online games. I have played MMOs with it in the past, but you really don't want to play anything that requires faster than a one or two second response time.

 

That's a huge assumption. For starters it assumes you're making a game...

 

My point really is that if you're on say a games website with 100 Unity games, you only have to download the plugin once. Is the same true with WebGL games? If not it is a serious barrier. More of a barrier than downloading a plugin once. (Or joining OnLive once).

 

According to the last post by jonas, it is true so long as the games use the same version of Unity.

 

True for the Web Player, not true for WebGL.

 

Check out JSZap it's a compression approach that uses the languages syntax to aid in compression something called an Abstract Syntax Tree, they report getting better than 10% file size reduction compared to gzip. In a way it's a smarter compression system, tailored to the job.

Update Good lecture on JSZap -> https://www.usenix.org/conference/webapps-10/jszap-compressing-javascript-code

*** Warning blog post below has some dodgy links, use links only with protection! ***
And this is a blog post on the subject of extreme compression of javascript. Where people are including the decompression process in the javascript to self decompress (LZMA?), or compressing to a PNG texture?!

 

This whole "plugins must die" thing does seem a bit odd considering all of the sites using Flash/Shockwave for instance as well as the games. It doesn't appear that having to install Flash was a showstopper. I mean it was as simple as if people wanted to use the site or wanted to play the game they installed the plugin. Sometimes I think these kind of changes are driven more by a "CAN we do it? The tech seems to be at the point. Yeah we CAN do it more or less so yeah let's do it" thought process than a "we NEED to do it" thought process.

Not for Unity I understand why they see a need to do it. I meant Google or whoever is driving this thing.

 

Plugins needed to die, if for nothing else for security reasons. Average users are not as keen to avoiding malware/viruses through browsers as you might think.

 

Maybe Unity should talk to Google about including the Web Player with Chrome, similar to how Chrome handles Flash.

 

That won't change anything. Flash is using the PPAPI in Chrome, while the WebPlayer is still using NPAPI. The problem is that Chrome is shutting down NPAPI. The WebPlayer would end up being shipped with Chrome, but deactivated or later on completely useless, because it is based on NPAPI.

 

I believe Shiloh's point was to transfer the plugin from NPAPI -> PPAPI.

That will at least give ~80% of the market (Chrome + IE). As for firefox... not sure when they plan to completely remove NPAPI. After all, Unity already builds two types of plugins no? ActiveX and NPAPI... spending some time building the PPAPI plugin will give them 100% browser support for at least as long as;

- It requires for WebGL 2.0 to mature instead of forcing their developer base to adopt an immature technology.
- Firefox drops NPAPI (so we lose FF support which is not as bad as losing Chrome)

Being completely dependent on my user-base's browsers, that whole ordeal is terribly frustrating.

I have to support IE, so I will need to build both WebGL and WebPlayer versions of my products and go back to the terrible old days of browser fragmentation.

If (Chrome > ?? || FF > ??) => WebGL
else => WebPlayer

And we all know that the WebGL version is different from the WebPlayer so I'm doubling my maintenance / QA / support burden... easily.

Ugh...

 

Any graphs?

 

TBH. I think just give up on making a Unity webplayer. It's fine as a gimmick. But to actually make it so that it has fast loading times would probably take all Unity employees working full time 2 years to do and a complete rewrite. I'd rather they just concentrate on making things like the UI text field work properly for mobile. Nobody ever made money from web games anyway.

 

There are other uses to the Web Player.

Elearning is a huge fan of Unity and its one domain that neither Unreal, CryEngine, Source Engine or any other engine has any footing...

 

Is it just me or is the sound in this demo flipped? I shoot a bot to the right and hear the explosion from the left speaker, and the other way around.

The fullscreen button also doesn't work:

 

That is exactly what I meant. Convert the Unity Web Player from NPAPI -> PPAPI and partner with Google to include the new PPAPI based Unity Web Player built into Chrome. That would get Unity Web Player support on par with Adobe Flash Player support. Meanwhile, keep improving WebGL since WebGL is obviously the best long term solution.

This would be vastly better than hoping the existing WebGL solution is good enough at the moment Google drops NPAPI support from Chrome.

 

Your logic following this is sound, but your premise is flawed. Or at least different from my perception of the web market. Sure, serious gamers have no issue assessing the security risks of a plugin, and installing it, but serious gamers are not where most of the web player games (or my web games at least) are targeted. Serious gamers go to steam and download the game properly. Downloaded games are always better then web based games.

Web based games are a market for those that do not want to download and install a game on their PC. This can be casual gamers that are just scrolling through, playing a few minutes on each game till they find something they like. Or it could be there are technical reasons for not installing a game on the PC (like an work or school computer, or parents paranoid about security). These technical reasons normally limit installing the web player as well.

In my experience probably about half of users get turned off by the requirement to install a plugin. Combine that with the fact that the plugin has required tricks to work in chrome for at least the past year, and you can understand why I'm very happy to abandon the web player. Casual gamers don't do tricks, especially when the browser comes up and recommends against it.

 

The caveat to this, as I stated earlier in the thread, is that PPAPI has less capabilities than WebGL.

 

Indeed. Especially when you understand that real-time 3D doesn't necessarily mean "game", and that even games aren't all developed without any external oversight.

 

Jonas could you tell us anything about upcoming UNET and WebGL? Does it mean WebGL will have multiplayer capabilities out of the box with UNET? Will it work similar to the web player version in terms that only Master Server is required to establish connection between players? Currently, I am using players' computers as servers. A player who hosts a game becomes an actual server and when he quits the whole game disappears, will this solution still possible with UNET and WebGL?

 

Guess i'm late on this topic...Got the official notice on FB.
Chrome is one of the more stable browsers we have tested...too bad!
1 down 3 more to go...LoL

 

That is very unfortunate indeed... it would had helped soften the blow a lot.

Unfortunately, browser fragmentation isn't going away any time soon... I will have to continue distributing to the WebPlayer for IE11, IE10, IE9.

http://gs.statcounter.com/#desktop-browser_version-ww-monthly-201501-201503-bar

Nevertheless, thank you for taking the time to discuss with us here. Very much appreciated.

 

Ha ha ha! That's golden. This could blowup in Google's face if public perception becomes Chrome is broken or otherwise just not "up to the challenge".

EDIT: In fact to help a tiny bit with this I will post on my FB page that Chrome will soon be broken and anyone using Chrome should consider switching over to Firefox now so they can keep playing their games.

 

You mean the same public that was satisfied with the sorry excuse that was Internet Explorer 6?

 

Interpreted languages, JavaScript in particular, are slow. Compiled languages (even if to just bytecode) are fast. Deal with it. Also JS is not object-oriented, so I can't run following example (or equivalent) there:

Code (csharp):

1. public class Woman {
2. //...
3. };
4. //...
5. Woman Anya = new Woman();

 

Both Chrome and Firefox have Just-in-Time compilers.

http://en.wikipedia.org/wiki/V8_(JavaScript_engine)
http://en.wikipedia.org/wiki/SpiderMonkey_(software)

JavaScript is a prototype-based object-oriented language. It has objects but without classes.

Code (JavaScript):

1. var Anya = {name: "Anya", age:21, country:"USA"}

Inheritance exists as well.

Code (JavaScript):

1. var animal = {eats:true}
2. var rabbit = {jumps:true}
3.  
4. rabbit.__proto__ = animal
5.  
6. alert(rabbit.eats)

http://en.wikipedia.org/wiki/Prototype-based_programming
http://javascript.info/tutorial/inheritance

 

So if browsers dynamically compiled javascript to 'safe' machine code then they could be as fast as any other compiled language?

 

ecmascript 6 has classes, already supported on some browsers like Mozilla. For the moment I write all my stuff in ec6 javascript and just use traceur to generate ec5 compatible js, works pretty well.

 

That's basically what asm.js is. http://blogs.unity3d.com/2014/10/07/benchmarking-unity-performance-in-webgl/ Also, Javascript being object oriented or not (although it is, of course) isn't particularly relevant in this case.

--Eric

 

Just tested on the little "known" Opera, and unity performance just blow thru the roof.
FB should just "buy" them over, and make it "officially endorsed" browser....

Disclaimer : i'm not associated with opera in any capacity.

 

I've contacted the Mozilla Blogger who was showing off Unity's WebGL 2.0 demo. It sounds like WebGL 2.0 could be arriving in a browser near you by the end of the year or early next year (ballpark timeline subject to change).

 

That Angry Bots WebGL is much faster than last year and on my same computer too.

It would be nice in Unity if when one created a new project it was always a WebGL project and that changing that platform to other platforms would create sub-projects of the WebGL project in subdirectories by importing and recompiling only the relevant scenes and assets included in the Build Dialogue for that platform. Then switching platforms for a project would be fast and efficient and that would, in effect, make the top level WebGL project become little more than a sanity checked top-level repository for all of your Unity Assets or rather make it possible to treat the project like an asset repository.

So Unity would need to create new file types - project files to be saved in the top-level webGL project as well as platform build files that described how to build the project for each platform and which scenes need be included. Also, all those different Project Setting files need to be included as part of the new sub-project file definition. The WebGL top level project would still use those things too but ideally you'd want to create a sub-project WebGL project definition and use the top-level only as a first level asset import sanity check as an general asset repository.

Not sure if such a change would be a big crimp in the value of Unity Pro SCM asset management services, repositories, and tools or not. I've never had Unity Pro.

 

What will be interesting is when Vulkan and DirectX 12 are released and are used to power WebGL and WebGL 2.0. We should really start to see some amazing WebGL demos.

And once Simd and multi-threading and further optimisations and enhancements make it into javascript and browsers things are looking up for WebGL.

Mind you it could do with a way to store game engines or frequently used/reused blocks of javascript to reduce download times.

And more efficient ways to compress the data.

 

Some time ago, don't remember where, I saw a demo of HTML5 implementation of 7Zip unpacker. It wasn't unpacked server side as it worked even with "file:" links. You'd put url to 7zip file you wish to unpack, then if there were any images inside, it'd show them.

As 7z files have great compression ratio (better in fact than rar), I think if Unity team could make it work for their engine, it could decrease amount of data WebGL version would have to download.

//edit: Here is one of many lzma decompressors written in JS: https://www.npmjs.com/package/lzma-purejs
I was told by Google that LZMA is used by 7zip in 7z format.

 

hm.. this is really some bad timing with Ludum Dare happening this weekend. As I read, Chrome restricted this NPAPI support on April 14th (Chrome v42). Lots of people chose Unity as their engine in this game jam and Web Player was really a good choice to have. Games were fast to load (once you have plugin) when rating multiple games.
When I tried WebGL export (Unity5) on some of my existing LD games, it was indeed 35MB instead of 2MB (really slow loading times) and game became 3-5x slower (without any changes to code). Not sure Unity's WebGL is widely usable in its current state.

 

You can re-enable support in Chrome under "chrome://flags/#enable-npapi". Or you can use Firefox and enable the sandbox flag "dom.ipc.plugins.sandbox.default" under "about:config".

Chrome's method is supposed to stay in place till September and I think Firefox's is indefinite (or undecided).

 

I notice there is no benchmark that deals with GUI. What's the story there, is GUI code slower or faster in WebGL - my limited tests would say possibly slower. But you have no benchmark test for it?

 

How much of the WebGL package could be hosted by Google Hosted Libraries ?

 

http://forum.unity3d.com/threads/splitting-up-engine-javascript-from-game.321797/

 

Any news on when Web GL 2.0 will be released and when Unity will be able to build to it? This is the crucial information.

I'm building for the web right now, and my current only option is to use the unsupported Unity plugin.... WebGL only being capable of OpenGL 2 quality 3D is a dealbreaker.

 

Kongregate is not going to be happy about this.

 

They will be fine, it's not like they are one of us struggling indies trying to make ends meet.