RIP, sweet Unity Web Player. We hardly knew ye.

RIP Unity

Here's the boring tech stuff: Chrome now disables NPAPI plugins by default, and will begin blocking them altogether starting in April. Long story short: The Unity Web Player—the plug in that runs most online mid-core game content—will no longer be viable on PC gamers' most popular browser.

Today's experience (Chrome V40) is already pretty bad:


And it's only gonna get worse.

But a spark of hope: Unity has announced the (frankly amazing) ability to export web-ready JavaScript/WebGL in their new Unity 5, and even thrown up some sample 3D games running fairly decently in the browser.

Awesome! But... (Always a but)...

Warning #1: Exporting to WebGL will miss some of important Unity3D features like:

  • Sockets (multiplayer games)
  • Threads (optimizing performance)
  • Fancy Audio (no 3D sound, no special effects)

Warning #2: In tests we've done, the minimum library size seems to be arond 100 Megabytes! That's even big for an app, never mind a web game.

Warning #3: No matter how good Unity’s WebGL conversion may be, there will be major browsers -- especially on mobile -- that won’t support the full standard for a few years. So it won't work on Firefox, Opera, Android browsers, or pre-iOS8.1 versions of Safari.

Ultimately, NPAPI deserves to die. It’s a Good Thing for browsers to all use one open set of standards—the same code should run similarly anywhere. But in the meantime, as with anything related to web standards, there’s going to be a bit of a poop-storm.

We’ve been experimenting quite a bit on behalf of clients worried that their Unity games will no longer work for a chunk of their existing web audience, and recommending two options:

1. Port your game entirely to Canvas (non WebGL) HTML5.

This can actually be surprisingly straightforward, especially for Unity2D titles, and has some big advantages:

  • The game will be be playable on mobile as well as PC browsers.
  • You can avoid the drop off in installs that currently happens when people are asked to install the Unity player.

But of course there are trade offs:

  • Due to the need to check things out on so many platforms, HTML5 code takes longer to test and maintain -- 25% longer in our experience.
  • Be sure to use someone with a lot of HTML5 experience if you do this as there are significant “gotchas" with how to deal with graphics, memory, and audio.
2. Create a hybrid between Unity’s converted project and additional HTML5 components.

It doesn't hurt to try using Unity 5's WebGL export and see what comes out the other end. If there are just a few issues, they can be addressed by hand.

  • For example, converting sockets to WebSockets, which has pretty universal browser support ( This involves a bit of switcheroo work on the client as well as game server.
  • Using tricks w/ audio sprites to achieve decent sound effect management across platforms.
  • Hand-massaging textures and optimizing 3D scenes.
  • Breaking up scenes into smaller, loadable packages and adding nice loading screens.

Not to mention the warnings we itemized above.

We’ll have to wait and see what the final Unity 5 release brings us, of course, to know exactly what will and won’t work well “out of the box,” but a hybrid approach should allow the majority of games to roll out w/ equivalent quality to the old Unity Web Player version.

We’re continually doing more testing and experimenting along these lines, so drop us a line to share experiences or to discuss the best way to keep web traffic alive for your Unity game.