Unity Web Player vs Web GL

Posted by (twitter: @Luke_Brown_09)
December 20th, 2015 1:28 am

I have seem many entries still using Web Player only and not providing a Web GL version as well. Is there any particular reason people do this? I personally like the idea of having both there. Since I use Chrome and Web Player isn’t supported having a Web GL version is a necessity as I really can’t be bothered switching over to Firefox.



10 Responses to “Unity Web Player vs Web GL”

  1. Dejvo says:

    the reason is, that the WebGL builds can be really buggy and many people use older versions of unity where you don’t even have WebGL build. Also, their main browser is firefox and they can’t be bothered switching over to chrome. but if there’s unity web player only, open it in firefok and play. i have fount out, that it’s as fast as opening a new tab.

    anyway, it’ll all become a thing of the past because soon, no browser will support Unity Web player

  2. Frenchie says:

    I tried compiling my game to WebGL. It crashed in the first frame on a cryptic JavaScript error. I’ll take the battle-hardened web-player over the just out of beta WebGL build. I don’t want people thinking my game crashes because of bugs that I have no control over

  3. thebrickanator says:

    If you don’t want to leave chrome I have discovered a replacement browser named ‘Citrio’ which is built from the same base as chrome and works exactly the same as chrome (retaining bookmarks, extensions, and account details) however unlike chrome it actually has support for these web players, has a 6x faster download speed, a video down-loader, and torrent client built in.

    It works very well for me in speeding up ludum dare voting so I suggest you try it out 😀

  4. YinYin says:

    WebGL simply doesn’t support all features yet.

    It has a lot of problems with lighting, shaders and mouse input.

    Most of the time you better target a build format from the very beginning and that will limit how/what you can do. Switching over late is not a quick and easy option for webGL yet.

  5. MemoryLeek says:

    Also, Web Player does not work on Linux, Web GL does.

  6. Efuvex says:

    I personally use Unity 5, and I love the concept of WebGL. It’s great to have something that is pretty much “pure web” – I can use it in any real browser without plugins or a web player for it. That’s as far as it goes though for me though. Firstly, its new, I haven’t used it extensively yet, and I’m sure few have as it was only recently upgraded from testing status. In my few uses of it, I have found it to be extremely slow – my projects run faster natively on my testing iPhone 4S (5 year old hardware?) than on WebGL on a high end MacBook Pro. Games have low framerate of any sort in my experience, and lastly I hate how buggy the fullscreen feature is. On web player you right click and go fullscreen – it’s out of the way, but it works – on WebGL (maybe just me) I find that the dedicated fullscreen button rarely works when clicked.

    Clearly with Chrome starting, and with the rest of the browsers dropping support in suit, WebGL is the future of Unity web publishing – but in its current state I feel that this will cause problems with a lot of developers given that Unity’s major selling point is cross compatibility, most of which is the web rather than OS specific

    – Topaz

  7. WebGL wasn’t officially supported until 5.3, which was launched like 3 days before LD34, I tried to install it and got a few errors so didn’t want to deal with the hassle of using an untested version. Because of this I put out a WebPlayer build. I have since gotten 5.3 working and built a WebGL build and have tons of lighting/shadow issues, so its a toss-up really: have a version that works in everything but Chrome, or have a version that works in everything but the lighting is screwed up. :( Eventually when WebGL is “fixed” I’ll be doing all of my builds using that.

  8. Codexus says:

    Because WebGL is a poor alternative to the webplayer.

    The webplayer is the same compiled code that runs the same engine as in the editor and stand alone versions. Everything will run the same with one click, no problem.

    WebGL suffers from the same javascript compatibility issues that have plagued javascript for 20 years. You still end up with a result that runs slightly differently and needs to be tested in every browser. So you need to test constantly for WebGL right from that start and be willing to give up on using any feature that just randomly won’t work.

    In practice, I tested making a WebGL build of my finished game, and not surprisingly it didn’t work.

  9. Ping78 says:

    Though i like the idea of WebGL. It does not work (enough) yet.

    Here’s some reasons why people doesn’t port to WebGL:
    You must have 64-bit system to port.
    There will be (sadly) some sort of bug which makes so you won’t publish your game to WebGL.
    You must have updates (somethings like drivers, browser, OS) in order to play, some people doesn’t update (which has its pros and cons).
    There is memory (allocation) issues that stops people from playing.

    My experience when porting to WebGL:
    In LD32 I tried to port my game to WebGL, thats how I found out about the material/”rendering”/lighting/shadow problems that other people are talking about.
    In LD33 when I tried porting to WebGL I was reintroduced with keyboard key bug there the keyboard key presses feels like you have 0-4 fps even though the rest of the game runs fine.
    this.LD I think that WebGL might work for my game, cause it doesn’t use keyboard, it uses simple materials and unity 5.3 probably has some improvements;

  10. FrozenCow says:

    My game’s gameplay element was to use light to grow bacteria. This uses spot-lights and normal maps. In WebGL lights just weren’t visible and normal maps did not work. The player wouldn’t know what to do.
    I did thought of changing the ‘real’ light into sprites and just dropping normal maps, but that would certainly make the game look bad (or at least less nice).

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]