First impressions of Unity WebGL deployment

Posted by (twitter: @AlexanderBirke)
April 17th, 2015 11:11 am

After having read Mike Kasprzak’s pre jam post that the Unity webplayer has been discontinued in Chrome, I decided to look into the new beta WebGL deployment option. I thought I would share my experience so the rest of you jammers out there can make an informed decision beforehand if this is the right option for your game or not. You can check out a test build I did here (controls are A, D, S, W, Q, E and mouse). My test build was done on Unity 5.0.1 and tested with Chrome 42.0.2311.90 m and Firefox 37.0.1 on Windows 8.1.

Build times are really really slow

First of it takes a long time compared to other platforms to make builds for WebGL. You can adjust how much optimisation Unity should do on the build so you trade runtime performance for faster build time, but even with the lowest level of optimisation you still have to wait quite a while. For my very simple project it took about 4 minutes to do a non optimized build and 6 for the most optimized build. Not much you can really do about it except taking more coffee breaks or maybe switching to either webplayer or standalone builds while you are working on the game and only use WebGL to perform final builds.

Get used to looking at this

Get used to looking at this

Performance is not super great

There’s already a good blog post from Unity on how performant WebGL builds are compared to native builds. In short you can roughly expect half the performance of what you get with a webplayer build but it depends a lot on what features you are using. In my fairly simple example there’s a fair bit of framerate stuttering on my laptop for example. If you are in doubt if your game idea will work in WebGL I’d recommend taking a look at the above link.

Cursor Juggling

WebGL builds supports full free mouse look but the player will have to click a popup that allows the content to take control of the cursor.  However if the game gets unfocused it will result in the cursor being stuck at the edges of your screen which makes games with free mouse look unplayable from that point on. This is problematic if the player wants to fullscreen your game since in the default Unity web template this is handled with a button. The solution to this is either automatically fullscreen the game when it loads in as in my demo or start your game with a button that also fullscreens it as they have done with the Dead Trigger WebGL demo. The later is definitely the more elegant option.

Other oddities

When you upload your build to your server be sure to exclude the .htaccess file Unity generates along with the rest of the build files. At least for my web server it meant the page would not load.

Remember to delete this when you upload your game

Remember to delete this when you upload your game

The Vimium plugin in Chrome also steals the input from the D key so it might be worth putting in a note on your webpage that it is adviced to disable that plugin first before playing your game if you use standard FPS controls.

Final Thoughts

WebGL is still very much a beta feature but I think it is definitely ready to be used for jamming. If you want to know even more about WebGL deployment, the documentation on it is definitely also worth a look. I am looking forward to see what the rest of you daring jammers will create with it!


9 Responses to “First impressions of Unity WebGL deployment”

  1. Liam :D says:

    Thanks for the information, appreciated.

  2. SmilingCat says:

    Great info, I’m definitely more than a bit concerned about using the WebGL platform in Unity. How did your build sizes turn out? For me, without compression (which I think the .htaccess file is supposed to enable), a build of an empty scene with the default settings was over 100MB.

  3. I’ve had a few similar problems while porting my games to webgl.

    Sound is not great; the exporter seems to compress the hell out of them. Mp3s sound like they’re in 8bits. You can override the setting by selecting the sound file and clicking “Override for WebGL”.

    I’ve had a bizarre texture compression problem on only some of my images; again, the fix was easy. Click the image and select “Override for WebGL” then choose Format >> Truecolor.

  4. Birke says:

    @SmilingCat That’s a point I had not considered and looking into the .htaccess file it seems you are right. From what I can tell it either only pulls down the assets in the Compressed folder or the ones in the Release folder depending on if you have the .htaccess file present or not. My release folder was 31Mb while the compressed folder was only 6.3 Mb so there’s definitely a gain in download time if you can get it to work. I might give it a shot during the jam to get the compressed version to work.

  5. tjxx says:

    I’ve had a few issues recently too with the WebGL exporter in Unity 5. Something that I found out is that any use of multithreading, including libraries from the asset store may not work at all if the application using them is ported to WebGL. This is due to Javascript not supporting multiple threads.

  6. egowall says:

    I’m very interested in articles written about various issues related to moving to Unity 5 and WebGL.

    We’re in the process of making that move with Egowall and have written several articles about our experience. It has not been easy and we’re not all the way there yet.

    If you’re interested, the articles are accessible from this page: http://blog.egowall.com/our-journey-to-webgl; we welcome any comments or feedback.

    Thanks!

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]