IntoScience is an interactive educational platform built using Unity. It is used in thousands of schools across Australia and the globe. It recently made the leap to WebGL to continue delivering features to chrome-based users. In porting a huge amount of content to this new technology, you could say we learned a thing or two. Here we share the highs, lows and hot-fixes in moving a massive product to a post-plugin existence.

1. IntoWebGL:
A postmortem of porting
to a post-plugin
existence

2. Ryan Alcock
ryan.alcock@intoscience.com
Rob Lee
rob.lee@intoscience.com

3. What is IntoScience?

6. IntoScience is large
● 124 unique activities mapped to curriculum.
● 6 interactive 3D environments.
● 38 ‘quests’ (including multi-part, ambience & portals)
● Multiplayer live science quiz.
● Always on-line.
● Teacher control over student navigation.
● Reporting
● And much more!

7. IntoScience is Cross-Platform
● WebPlayer
● iPad
● Standalone (Windows & Mac)
● Windows App Store
● Working Android prototype
● And now… WebGL!

8. Our customers are schools
● Slow networks
● Slow machines
● Restrictive firewalls / proxies
● Limited IT support

9. Basically, IntoScience is rather ambitious
● Small team (<15 people)
● Lots of 3rd party Assets from the Asset Store
○ NGUI
○ AStar pathfinding
○ Marmoset
○ Json utils
○ Tween utils
○ Playmaker
○ Mega-Fiers
○ ...and many more
● Lots of Playmaker driven content (eep)
● So the LEAST likely app to be able to port smoothly into a new platform like
WebGL

10. Build System

11. Texture Streaming

13. Why WebGL?
● Chrome were the first to move away from the old plugin structures.
● There is no Chrome without using WebGL
● Chrome is 46.1% of our browser users (28% of all platforms)
● No choice but to support it if we want to keep using Unity (we do!)
● Google has forced our hand in the short term
● In the long term everyone will need to use it anyway because…
● No plugin!
○ Makes it a lot easier to deploy to schools
○ Easier to release new versions

14. WebPlayer is dead
● The rest of the vendors will soon be following the same path as Chrome
● WebPlayer won’t exist in Unity 5.4
● Reality is WebPlayer is already gone. You should already be using
WebGL.
● The problem?

15. WebGL is still a ‘Preview’
● Not quite there yet… but close!
● Clearly a work in progress.
● Must be treated as an entirely new platform
● Many missing features
● Critical bugs from all sides
● BUT!! It’s still possible to get something working

17. IntoScience on WebGL
Current stats
● Initial download of 21Mb of compressed data and javascript.
● After the initial download the results should be cached.
● But still have to compile the javascript every time.
● About 10 seconds load time on an i7 with fast internet. (after initial load)
● 5 to 6 minutes initial load time on a slow chromebook
● 1 to 2 minutes on subsequent loads.

18. IntoScience on WebGL
First release (Google September deadline)
● Had problems with memory
● Tended to crash if re-loading the page.
● 3D scene performance was poor.

19. IntoScience on WebGL
Second Release (World Education Games)
● Lots and lots of students (800,000)
● Scary
● Solved the problem with the memory and stability
● Improved 3D performance.

20. What went right?

21. What went right?
● Released on time.
● Multiple releases in short period of time.
● Most of the content ‘just worked’
● Unity managed to fix the most critical issues before the deadline.
● Still sharing the codebase between all our platforms.
● Content team didn’t have to worry about the WebGL differences.
● Now have a plugin free environment.

22. The Bad Stuff or: Tips and Tricks to
Avoid The Bomb

23. What went wrong?
● Being on the bleeding edge of Unity releases is problematic.
● Bug fixing ‘whack-a-mole’
● WebGL was/is ‘coming in hot’ which means we were too.
● Cache fun.
○ Always be clearing
○ Require production asset versioning.
● Some audio assets crash on import.
● Lots of memory issues
● Lots of performance issues

24. WebGL performance
● WebGL is super hard to profile accurately. Very unstable at the moment.
○ To profile memory, start with the profiler turned off. Switch it on and take a memory snapshot
before it crashes.
○ Don’t profile memory usage in the editor game window.
○ Luckily, framerate profiling in the editor is almost accurate enough to point you in the right
directions.
○ CPU will pretty much always be the problem at the moment
○ Reduce draw calls as much as possible
○ Make sure your scripts are optimised.
● Framerate of WebGL is about half of WebPlayer for the same scene.
● Using asset bundles turns off static batching. Manually recombine with
StaticBatchingUtility.Combine(..)

25. Cross-Origin Resource Sharing (CORS)
● CORS!
● WebGL requires CORS headers for all the www calls you make.
● This means you have tell your webserver to add them.
● http://enable-cors.org/server_apache.html
● There are no movie textures in webgl. Use the WebGLMovieTexture plugin.
● Add video.crossOrigin = “anonymous”; to the .jslib file

26. Our WebGL App Goals
● Smallest possible initial download.
● Bundle/Stream everything.
● Minimise wait time with scaling asset detail levels.
● Avoid third party plugins!
● Remove all exceptions (not easy).
● Generally try to reduce codebase size.

27. Asset Bundles
● “chunk” your asset bundles as much as possible.
○ Promotes better caching.
○ More flexible detail level scaling.
○ Make sure to AssetBundle.Unload(..) asap.
○ Only load/unload one bundle at a time.
○ Download one asset at a time.

28. Asset Bundles
● Regularly sanity check asset bundle contents.
● Don’t use the old asset bundle system. (bugs)
● Use crunched texture compression for everything.
● Compress all your meshes as much as you can.

29. Code Stripping and Asset Bundles
● Use namespaces to fix stripping problems.
● Brute force the rest. Find the errors and add to list.
○ Look for “Could not produce class with ID XXX”
○ http://docs.unity3d.com/Manual/ClassIDReference.html

30. WebGL Memory
● Memory usage was one of the key limitations
● Try set your WebGL Memory Size to a max of 256 for
stability. This can be hard.
● Turn off ‘Data Caching’ for now!!
● Recommend you don’t use www.
LoadFromCacheOrDownload(..) for now!!

31. Minor Issues

32. WebGL Player Settings
● Our current Unity Player Settings

33. Random Tips
● Use the chrome developer tools. (Ctrl + Shift + I)
● Don’t try inspect/debug the .js files!
● Chrome can throttle bandwidth now. Useful for testing for clients with poor
internet.
● Use the .jslib plugins for unity->javascript communications.
● Setup a local Apache server to test your stuff. I use XAMPP.

34. Random Tips
● For too long we didn’t have a backspace key!!
● Here’s useful snippet for the HTML wrapper: (Backspace and ESC blocking)

35. TIP: Testing Webgl Apps
● Unity dev may not have experienced a lot of these
issues before.
● Maintain a local web server.
● Modify local hosts file to allow cross-domain fakery.
● e.g. Add:
○ 127.0.0.1 mydomain.com
○ This will let me access my local server via http:
//mydomain.com and test the CORS setup.

36. The Future

37. The Future
● Multiple vendors working on making WebGL better.
● New technology coming to improve WebGL/javascript
performance
○ WebAssembly - faster, smaller download/compile times
○ SIMD.js - faster math stuff
○ Shared Array Buffers - threading
○ Unity tools for code stripping.
● Stick with it! Things will constantly improve!

39. http://intoscience.com/signin/
Questions and Live Test!!

40. Questions?
IntoScience
http://www.intoscience.com
Ryan Alcock
ryan.alcock@intoscience.com
Rob Lee
rob.lee@intoscience.com