Aaaaa! and Jack Lumber in WebGL Humble Bundle!

Aaaaa! is now officially the first commercially available Unity WebGL game!!1! You may have seen the big news today, but for those who’ve been living in an Internet-less cave, starting today through October 28 you can check out the brand spankin’ new Humble Mozilla Bundle. Update: Jack Lumber has also been ported to WebGL and included in the bundle! The scientists at Owlchemy were given the unique opportunity to work closely with Unity and Humble to attempt to bring one of our games, Aaaaa! for the Awesome, a collaboration with Dejobaan Games, to the web via technologies like WebGL and asm.js.

I’ll attempt to enumerate some of the technical challenges we hit along the way as well as provide some tips for developers who might follow our path in the future.


Unity WebGL exporter

Working with pre-release alpha versions of the Unity WebGL exporter (now in beta) was a surprisingly smooth experience overall! Jonas Echterhoff, Ralph Hauwert and the rest of the team at Unity did an amazing job getting the core engine running with asm.js and playing Unity content in the browser at incredible speeds; it was pretty staggering. When you look at the scope of the problem and the technical magic needed to go all the way from C# scripting down to the final 1-million-plus-line .js file, the technology is mind boggling.


Thankfully, as content creators and game developers, Unity has allowed us to focus our worries away from the problem of getting our games to compile in this new build target by taking care of the heavy lifting under the hood. So did we just hit the big WebGL export button and sit back while Unity cranked out the html and js? Well, it’s a bit more involved than that, but it’s certainly better than some of the prior early-stage ports we’ve done.

For example, our experience with bringing a game through the now defunct Unity to Stage3D/Flash exporter during the Flash in a Flash contest in late 2011 was more like taking a machete to a jungle of code, hacking away core bits, working around inexplicably missing core functionality (no generic lists?!) and making a mess of our codebase. WebGL was a breeze comparatively!

The porting process

Our porting process began in early June of this year when we gained alpha access to the WIP WebGL exporter to prove whether a complex game like Aaaaa! for the Awesome was going to be portable within a relatively short time frame with such an early framework. After two days of mucking about with the exporter, we knew it would be doable (and had content actually running in-browser!) but as with all tech endeavors like this, we were walking in blind as to the scope of the entire port that was ahead of us.

Would we hit one or two bugs? Hundreds? Could it be completed in the short timespan we were given? Thankfully we made it out alive and dozens of bug reports and fixes later, we have a working game! Devs jumping into this process now (October 2014 and onward) fortunately get all of these fixes built in from the start and can benefit from a much smoother pipeline from Unity to WebGL. The exporter has improved by a huge amount since June!

Initial issues

We came across some silly issues that were either caused by our project’s upgrade from Unity 4 to Unity 5 or simply the exporter being in such “early days”. Fun little things such as all mouse cursor coordinates being inverted inexplicably caused some baffled faces but of course has been fixed at the time of writing. We also hit some physics-related bugs that turned out to have been caused by the Unity 4 to Unity 5 upgrade — this led to a hilarious bug where players wouldn’t smash through score plates and get points but instead slammed into score plates as if they were made of concrete, instantly crushing the skydiving player. A fun new feature!

Additionally, we came across a very hard-to-track-down memory leak bug that only exhibited itself after playing the game for an extended session. With a hunch that the leak revolved around scene loading and unloading, we built a hands-off repro case that loaded and unloaded the same scene hundreds of times, causing the crash and helping the Unity team find and fix the leak! Huzzah!

Bandwidth considerations

Above examples are fun to talk about but have essentially been solved by this point. That leaves developers with two core development issues that they’ll need to keep in mind when bringing games to the Web: bandwidth considerations, and form factor / user experience changes.

Aaaaa! Is a great test case for a worst case scenario when it comes to file size. We have a game with over 200 levels or zones, over with 300 level assets that can be spawned at runtime in any level, 48 unique skyboxes (6 textures per sky!), and 38 full-length songs. Our standalone PC/Mac build weighs in at 388mb uncompressed. Downloading almost 400 megabytes to get to the title screen of our game would be completely unacceptable!

In our case, we were able to rely on Unity’s build process to efficiently strip and pack the build into a much smaller size, but also took advantage of Unity’s AudioClip streaming solution to stream in our music at runtime on demand! The file size savings of streaming music was huge and highly recommended for all Unity games. To glean additional file size savings, Asset Bundles can be used for loading levels on demand, but are best used in simple games or when building games from the ground up with web in mind.

In the end, our final *compressed* WebGL build size, which includes all of our loaded assets as well as the Unity engine itself ended up weighing in at 68.8 MB, compared to a *compressed* standalone size of 192 MB, almost 3x smaller than our PC build!


Form factor/user experience changes

User experience considerations are the other important factor to keep in mind when developing games for the Web or porting existing games to be fun, playable Web experiences. Examples of keeping the form factor of the Web include avoiding “sacred” key presses, such as Escape. Escape is used as pause in many games but many browsers eat up the Escape key and reserve it for exiting full-screen mode or releasing mouse lock. Mouse lock and full-screen are both important to creating fully-fledged gaming experiences on the web so you’ll want to find a way to re-bind keys to avoid these special key presses that are off-limits when in the browser.


Secondly, you’ll want to remember that you’re working within a sandboxed environment on the Web so loading in custom music from the user’s hard drive or saving large files locally can be problematic due to this sandboxing. It might be worth evaluating which features in your game you might want to be modified to fit the Web experience vs. a desktop experience.

Players also notice the little things that key someone into a game being a rushed port. For example, if you have a quit button on the title screen of your PC game, you should definitely remove it in your web build as quitting is not a paradigm used on the Web. At any point the user can simply navigate away from the page, so watch out for elements in your game that don’t fit the current web ecosystem.


Lastly you’ll want to think about ways to allow your data to persist across multiple browsers on different machines. Gamers don’t always sit on the same machine to play their games, which is why many services allow for cloud save functionality. The same goes for the Web, and if you can build a system (like the wonderfully talented Edward Rudd created for the Humble Player, it will help the overall web experience for the player.

Bringing games to the Web!

So with all of that being said, the Web seems like a very viable place to be bringing Unity content as the WebGL exporter solidifies. You can expect Owlchemy Labs to bring more of their games to the Web in the near future, so keep an eye out for those! ;) With our content running at almost the same speed as native desktop builds, we definitely have a revolution on our hands when it comes to portability of content, empowering game developers with another outlet for their creative content, which is always a good thing.


Thanks to Dejobaan Games, the team at Humble Bundle, and of course the team at Unity for making all of this possible!

Graeme joins the Owlchemy crew!

If you’ve been following our Kickstarter updates, you may have seen our small featurette on Dyscourse programmer/designer/animator extraordinaire, Graeme Borland. He’s been working on Dyscourse for over a year now as a collaborator.

At Owlchemy, we have a core team of three (Alex, Devin, and Carrie) as well as a number of talented collaborators who we work with when creating our original games. These collaborators have been known to join us for a specific project and then move on to other endeavors while the core team remains for the next original game.

After many heated arguments (not really), we’ve come to the decision to bring Graeme deeper into the fold. We’d like to welcome Graeme to the ‘core’ Owlchemy Labs team for the rest of Dyscourse and beyond!


In typical Owlchemy fashion, we’ve Photoshopped him into a picture to make the ultimate Canadian composite image because, why not?!

We’re looking forward to concepting and designing our next game from the ground up with the help of Graeme’s magical dev skills.

VR Bender = Valve + Unity + VR + BUG + Good times

Owlchemy recently hosted an event in Boston called the Boston VR Bender — a week-long series of 3 events starting off with a weekend VR game jam, and ending with a VR drinking night at the Mead Hall in Cambridge. Unity did a post on their blog all about the event, so instead of paraphrasing, I thought I’d quote Pete Moss’ words, who was a huge help at the event!

Date: July 2nd, 2014

Over the last days of May and into early June, over 50 people from in and around the Boston game community gathered together for a VR game jam. The event was organized by Alex Schwartz and Devin Reimer of Owlchemy Labs in conjunction with devs who saw VR demos back at Steam Dev Days and wanted to do a VR Jam. So Valve and Unity went out to help. The purpose of the jam was to expose developers to positional tracking and low persistence.

To enable this, Valve brought along some prototype headsets with positional tracking using desktop IR cameras. A couple of us from Unity went along to provide support and witness the creativity of the community first hand. The event gave us all a chance to test the excellent new SteamVR Unity plugin being developed at Valve.

The participants split up into teams, some with just a couple of folks, others with full teams comprising programmers, artists and designers. There was only one rule – teams had to hit 95 frames per second (the refresh rate of the Valve prototype hardware), or their demos wouldn’t be shown at the showcase.

Getting 95 frames a second in 2 days was a huge challenge, and I can honestly say I wasn’t the only person to be surprised at the number of teams that succeeded, as Chet Faliszek from Valve put it: “All of the devs using Unity hit the frame rate. It really is a testament to Unity that people could deliver that high perf requirement in that short a time frame.”

One team built a simulator where the player was a giraffe, reaching its head through windows in a home searching for tasty treats to eat. Another team developed a playfield full of block buildings populated with small screaming humans and giant kaiju punching bags to give the player a sense of what it is like to be a giant robot with telescoping arms.

A further project involved using the rotation of the player’s head to cause a sea snake to swim underwater, a potentially nauseating experience, but with the positional headsets this sort of head movement seemed robust and the devs could keep the headset on for a long time without any ill effect. Additionally, one of the most simple, yet fun, games at the jam was made by a single person to simulate heading a goal in soccer – a game that yielded many calls to “beat my high score” during testing.

There were many times we were asked what a particular group should do, and the response was always the same: “I don’t know, and in fact no one knows yet what works in VR. So make something crazy and weird and lets find out how it feels in that world.” In so many ways, we are still in the very early days of VR, and we just don’t yet know enough or have enough experience to know what works and what doesn’t.

From my point of view, we are looking at a new era, similar to the push for 3D gaming in the 90s. Those early games are very primitive by today’s standards, and yet those early lessons are still with us and continue to inform game design. I believe the new wave of positional VR hardware is another huge step forward, and it will take years before we know collectively how to use it in the best way.

I was happy to see so many newbies to Unity pick it up and be able to produce content right away. Additionally, it was great to see seasoned professionals be forced to think through their design in a new way, knowing that they did not have a clear picture of exactly what it would look like during game play.

Earlier this year, at the Steam Dev Days, Alex and Devin from Owlchemy Labs gave a talk on authoring for VR, called Wild West of VR – Discovering the Rules of Oculus Rift Development. Go give it a watch to get a jump start on issues related to authoring.

Also, for an understanding of what the current challenges are, and where the current state of the tech is at, I recommend also watching Michael Abrash from Valve’s presentation: What VR Could, Should, and Almost Certainly Will Be within Two Years.

And for what will hopefully be a continuing and engaging discussion on VR authoring, join us in Seattle this August for our Unite Conference, where I will head a panel discussion titled The Reality of Authoring on the Virtual Frontier. In my imagination, the Future of VR is amazing, so let’s all work together to make it reality!

Thanks again to Unity, Valve, and everyone who participated! It was a KILLER event!

Here’s some additional imagery:

The VR jammers, from above!

Group shot from Monday night’s Boston VR meetup

The crowd on Monday night was huge!