Time for WebGL? Quicker virtual worlds in Unity3d

This weekend I helped a friend get a network connected Unity3D environment up and running. I have, of course, done this a lot. In fact it has generally been the focus of most of the dev projects the past 7 years. I guess that means I am past the ‘expert’, know it all, part and into mastery, when everything reminds you of how much you have yet to learn, in the vastness of a subject.
This time though I was faced with the deprecation of the Unity3D web plugin. I had seen the draggle facing out of the incredibly useful and powerful plugin due to the web browser developers taking away support gradually. I have used Unity3D for many years because of its flexibility in allowing me as a developer and creator to have the potential to target lots of running platforms from a single base project. The WebGl option has sat there for a while and I have experimented with the basics of what Unity3D creates. The problem is, when all the core routines are in the plugin, you provide your layer of code to make it do something. The Plugin is a collection of API’s and routines. When you switch to WebGL Unity3D, or any platform, has to provide a lot of the underlying function to support your application as part of the package. Also the plugin would typically have some permissions given to it by the user, that a WebGL page with a stack of javascript tucked away in a compressed file does not have.
Consequently I was not really expecting, without a lot of hacking, for my basic set of tools to work to allow me to create a standard multi user environment, and have it still run without the user having to do very much, other than access a web page. i.e. no install.
Surprisingly is did work though. I use Photon, and its default Worker demo as the basis to test things. When I pushed to WebGL instead of the web player it actually worked. There may be some backing off on which protocol it is using, as it negotiates the best way to talk to the other clients, but it worked without any hassle.

Interestingly it also worked, well nearly, on the iPhone. The Web plugin was never designed to work on any smartphones or tablets, instead you build specific apps for those devices. However, the basic demo actually started and connected on Safari on the Iphone. The problem was that the demo uses the old GUI code and not the fancy new Unity 5.0 user interface. So it has no idea about responding to touch inputs unless you put extra code into it. I may well give that a go to see where this deployment option is going. If it does actually work (despite not being supported) it further eradicates the need to package and build apps. People get the up to date version on serving.
Despite working straight away locally, I had a few more problems when i just placed the WebGL on my 1and1 server. The packaged up versions of all the code, with mine and Unity is stored in a several files a .jsgz, .memgz and .datagz which the unity loader.js wants to pull in. It decompresses them in memory at runtime. However the files were listed a .js, .mem and .data in the index.html. I think the generator looks for uncompressed versions first and then looks of the zipped versions. Somewhere in that I was get an error, but when I changed the generated index.html to look for the compressed files directly it actually worked.
I suffered from some caching problems with the .html file though, that made it seem it was not working. Having changed the internal URL’s and reloaded the page it still failed. Looking at the source I saw it had not changed. A shift/reload used to force a non cache version of the page, but that did not work, neither did closing safari. Renaming index to index2 did the trick. Some of this may be edge of network caching or 1and1, or the browser juts being too much in control. It is an old problem many developer have had over the years as the web has matured.
The good news, then, is that the Photon Unity Network – Free samples, with the Worker scene seem to connect across web browsers in a peer to peer way, just as the old one used to with the plugin, but now in WebGL. I have not tried Unity’s new networking but I assume it will work also. If the packets flow then that means there is some hope for voice, though it is a packet hog and the packages are few and far between to do voice chat.
It actually took longer to get a shared project up and synching than it did to get a custom little virtual world working.
There will be a lot of details that don’t work, how graphics are rendered, lighting etc. The entire, mature Unity3D plugin has to be rebuilt in bits of javascript, which sounds crazy, for each application. However, there are some clever optimisation routines that only provide the bits of the code that are needed, it seems. So everything old is new again and I can get back to making online environments quickly for customers and projects.