19 Feb Egowall and WebGL (Part 1): How We Got Here
As you know, Egowall is a 3D browser-based social platform which has been in production since March 2014.
It is built on a rich cloud-based architecture and we leverage the Unity3D Game Engine for its user interface.
This is the first of a series of blog posts in which we will share some behind-the-scenes information about our journey on the road to Unity 5 and WebGL™.
Google and the NPAPI
Google in 2013 announced that it would remove support for the NPAPI (Netscape Plugin Application Programming Interface) – and associated plugins – in its popular Chrome browser. Stating that the “NPAPI’s 90s-era architecture has become a leading cause of hangs, crashes, security incidents, and code complexity,” they established a two year plan to execute this plan.
Initially, Google established a whitelist for popular Chrome plugins (one of them was the Unity Web Player). But in 2014, Google began to block non-whitelisted plugins by default. Users were able to allow them for specific sites as needed, but this created a lot of concern among developers.
Like many developers, we were concerned with the problems associated with browser plugins and were looking for a more elegant solution. Late in 2014, Unity provided an update for its developer community.
They said, “[W]e are committed to supporting [the Unity Web Player] for as long as the browser landscape means it makes sense to do so. Even if your games cease to run on the Google Chrome browser, they’ll still work on other browsers such as Mozilla Firefox, Microsoft IE and Apple Safari.”
At that time, Unity was actively developing Unity 5 for WebGL, which they claimed to be “the best and safest long-term solution for running advanced 3D and 2D content in browsers.” Applications published using WebGL would not require a browser plugin.
That was to be the “more elegant solution.”
But Unity 5 for WebGL was still in beta at that time. It was not yet possible to migrate a released product like Egowall to a new development platform.
End of NPAPI Support in Chrome
In early 2015, Google removed the whitelist, causing all NPAPI plugins to be blocked in Chrome by default. They provided an override for advanced users to temporarily re-enable the NPAPI, but it was a less-than-optimal solution for the average user.
Egowall Release 3.0
Thanks to all the support and feedback we received from people we met at SXSW 2014. In June 2014, we started work on the next major release of Egowall – a one-year effort to implement a major feature upgrade and facelift.
We were still in active development when Unity 5 for WebGL was finally released in March 2015. After taking a long look at it, we determined that its initial release was simply not “ready for prime time.”
Since we could not ensure that our users would have the same quality experience with WebGL as the Unity Web Player, we chose to defer the migration of Egowall to WebGL until Unity addressed the concerns we had with the product.
But we are actively working to change that.
What We’ve Learned
Conversion of Egowall to WebGL is now underway.
It turns out that the process of upgrading a large, complex application to Unity 5 for WebGL is not as easy you might think – or hope. Beyond the fact that WebGL is significantly slower than native code, there are many other things to deal with.
In the coming days on this blog, we will talking about the issues we have encountered during the conversion. Our goal is to provide you with information to help you if you are faced with a similar effort.
So stay tuned to find out what we have learned, what we did to address the issues identified, and where we are in the process. Our story continues with Egowall and WebGL (Part 2) – Art and Asset Issues.
WebGL and the WebGL logo are trademarks of the Khronos Group Inc.
Continue reading: Egowall and WebGL (Part 2) – Art and Asset Issues