Lessons learned working with Webplayer, WebGL and Facebook
I founded Leviathan Games over 15 years ago, and since then we’ve been building web browser games (and just about every other type of game) using a variety of technologies including Flash, WildTangent, Virtools, and most recently the Unity Webplayer. Over the past 6 months, we’ve been working on “Big Buck Hunter Outdoor Adventures” for Facebook, a process that has taken us to the bleeding edge, resulting in one of the first Unity WebGL games on the market. In the entire history of browser-based gaming, I’m not sure I recall a more uncertain time for developers of web games. I am happy to say that Unity has really pulled a rabbit out of a hat, and given developers some amazing tools to get through this transitional period of web technology. Here is some of what we encountered to date during this ongoing development cycle.
The Recent Past
Getting users to install a plugin to power a web game has been a hurdle for ages – which is why the majority of web games were powered by Flash, which came preinstalled on most computers and browsers. Just a couple years back, we were seeing more than 50% falloff in our Major League Baseball Web / Facebook game that required the Unity Webplayer. When Facebook started pushing Unity to developers, and portals like Kongregate were announcing most of their millions of players already had Unity’s Webplayer installed, it seemed like things might be turning a corner. The promise of a true alternative to Flash was at hand. But then Google announced roadmap to drop NPAPI support in Chrome, the key underlying install process for Unity, Silverlight and the other plugins that powered most web games. This was nothing less than a death sentence for NPAPI plugins, since Chrome is the dominant browser.
Current Lay of the Land
As of just a few days ago (Sept. 2015), Chrome has indeed shut off NPAPI support. Most users are being auto-updated to the new version of Chrome, only to find some games and web sites are no longer working. Most developers are ‘patching’ this problem by detecting and directing users to other browsers, since the alternatives are in their infancy, and expensive to adopt. It baffles me to think Chrome will stay the course, especially if they see users turning to other browsers - but I think we have to assume they will.
For developers working with Unity, we’ve been told WebGL is the road forward. But this is the reality of how that looks:
Chrome: Only WebGL will run.
Firefox: Webplayer or WebGL will run.
IE: Only Webplayer will run.
All other browsers – Webplayer (if supported) or no options.
So unless you are willing to cut off a significant portion of your potential audience, the immediate road map for Unity games on the web is a dual release of Webplayer and WebGL support. Seeing this coming at the start of the year, that’s the direction we chose for Big Buck Hunter.
Right out of the gate, we ran into some serious migration tasks moving our codebase from Unity 4 to Unity 5, so that we could access the WebGL platform. We recreated our bundling tools based on the ‘new’ systems, rebuilt our “1 click build” system, and fixed up our Unity Cloud Build support (yes we use that, and its great – but the subject of a later post). Dozens of smaller tasks were at play as well, processing assets to be happy in the Unity 5 ecosystem. With migration tasks complete, we finally were able to attempt our first build to WebGL. We clicked “build” and we waited, and waited… It actually never completed. Ill spare you a lot of the details, but over the next several weeks we learned:
We had to build a micro version of our game, and turn on systems one by one to debug them separately. This likely would not affect ‘new’ projects unless you have a large existing codebase.
We must always grab the latest beta of Unity. The WebGL team was iterating so fast, and on a fundamental level, that it was easier to keep transitioning than it was to diagnose and report issues.
Reducing the codebase was vital. Build times were so long, mostly spent analyzing our source, that every file we could trim or shorten was noticeably effecting build times.
Making debug builds with exceptions etc. enabled was essentially unstable and pointless. Our code base is so large it only really works in release mode.
We made bundles in 1 project, and then had a ‘build’ project with no source files in it at all. This also cut build times down quite a bit, and incidentally is how you should use Cloud Build (not that it supports WebGL).
WebGL & Webplayer Development
You can’t run a WebGL build in the Unity Editor. At least, not in any meaningful way. So we would create game features in the Webplayer version, and get them debugged there. Then we’d move those features to the WebGL version, which had to be build and tested in each browser separately. On multiple occasions we have run into WebGL bugs that were browser specific, which is a real bummer to debug. The Webplayer had us largely spoiled in thinking that if something worked in one browser, it likely worked in them all. Even so, I can’t understate how much of a miracle it is to be able to build to WebGL –at all- the complexities of that problem are really astounding, and Unity did a great job making the whole experience comfortable for developers. If you get stuck on something WebGL specific, make sure to use the Unity forums. The other developers and Unity support staff are quite active.
We are using essentially identical code between Webplayer and WebGL, minus a few #ifdefs. Here you can see the two versions side by side:
You will note that shadows aren’t ‘soft’ or blended in the WebGL version. We may opt to just turn them off, or change our approach to ‘burn’ them into the terrain map. Speaking of which, we were originally using a nice multi-texture shader that blended between 4 textures for the terrain. We couldn’t get that working well in WebGL and so we reverted to a more simplistic single-texture approach. But for the most part, everything just worked once we got past a few sticking points in the code. Most of those were fairly obvious sketchy sections, using third party libraries or advanced c# language features like reflection. Also converting all audio to mp3 is tedious, but straight forward. Don't expect great audio in your WebGL games.
In mid summer we pushed a softlaunch of Big Buck Hunter to Facebook with just Webplayer support, and were seeing a largely Firefox and IE based audience. Chrome was still ‘working’ but only if you manually enabled NPAPI – a strange process at best. Moreover, our cost-per-installs resulting from the ads we ran were fairly high, since Chrome users were being shows ads but were largely unable to play the game. After the launch of the hybrid webplayer/webgl approach, our numbers drastically changed, to where Chrome now dominates our player base.
Here’s what that looks like in pie graph form:
The Road Ahead
We are still in a softlaunch period for Big Buck Hunter on Facebook, and will be officially going live during the Big Buck Hunter World Championships next month. Soon too follow will be the release of iOS and Android versions of the game. I would love to foresee dropping Webplayer support. It’s annoying to support more platforms than needed, and the overhead of testing all these browsers / tech combinations can’t be understated. However, because WebGL can’t viably be run in the Unity editor, and because Internet Explorer wont have WebGL support anytime soon, I think the Webplayer will be around for a least a year, and possibly a lot longer. Thanks to Unity though, for working with us to make this product launch possible, and for getting far enough, fast enough, to prove there is a viable way to make webgames during a strange, transitional period of web technologies. It should only get better from here.