Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WebGL and Unity: Best Practices - Vincent Vergonjeanne

1,147 views

Published on

EVERYDAYiPLAY was one of the first companies in the world to launch a commercial version of a large F2P 3D game using Unity WebGL export.I will go through this journey with you and share some of the issue we faced and all the solutions we applied to have a successful launch.

In this talk, Vincent described:
1. How to deal with lack of sockets and threads
2. Major rendering optimizations to further improve your FPS
3. How to deal with memory allocation, download constraints and debugging

Published in: Technology
  • Be the first to comment

WebGL and Unity: Best Practices - Vincent Vergonjeanne

  1. 1. WebGL and Unity Best Practices Vincent Vergonjeanne CEO - EVERYDAYiPLAY
  2. 2. Former CEO of Kobojo +50M registered users since 2009 $7.5M Serie A in april 2011 Up to 90 employees Who am I?
  3. 3. CEO of EVERYDAYiPLAY Self-Funded 24 employees Who am I?
  4. 4. WHY WEBGL WAS SO IMPORTANT FOR US?
  5. 5. Vikings Gone Wild • Oct 2013: Vikings Gone Wild on Facebook – Hybrid Flash/Unity WebPlayer – 3M registered users – Launched on iOS, Android 1 year later
  6. 6. Heroes of Paragon • June 2014: Start of Heroes of Paragon – Planned to launch with WebPlayer only – iOS and Android supported from beginning
  7. 7. • April 2015: Chrome kills NAPI – Strong impact on Vikings Gone Wild – Heroes of Paragon’s plan for Web are shutdown – We become a mobile gaming company
  8. 8. OUR FIRST EXPERIENCE WITH WEBGL
  9. 9. Early days • Jan 2015: We get access to Unity 5.0 beta – The game exported properly – We ran it …
  10. 10. • But early results were disastrous • 32 bits browser crashes most of the time during JS parsing phase • 64 bits browser pass the parsing, but early fps was terrible (2 fps in average). • The project.js file for Heroes was 60Mb uncompressed. Early days
  11. 11. • April 2015: Another try with official release • Same results • We are officially a mobile-only company Early days
  12. 12. THE BREAKTHROUGH
  13. 13. Breakthrough • Oct 2015: Facebook team pushes us to re- explore – We try again with 5.2.1 – We ran it and WOW! – Performances for the game was at 30 fps! – One main issue -> Massive Memory Leak!
  14. 14. Seeking support • Given early positive result we fully engaged ourselves to the port and connected with: – Facebook dev team – Mozilla WebGL team – Unity WebGL team
  15. 15. FROM PROTOTYPE TO RELEASE
  16. 16. DEMO
  17. 17. Issues to solve • Raw Socket – WebGL doesn’t support Socket and our game used Socket to connect over TCP-IP to our server. – We installed “Sockify” on our server and adapted client side to it
  18. 18. Raw Sockets • WebSocket – Concept it simple -> Wrap your raw socket around an HTTP call. Game Logic (TCP) WebSocket (HTTP) Game Server (TCP) WebSockify (HTTP)
  19. 19. Raw Sockets #if UNITY_WEBGL WebSocket m_socket = null; #else Socket m_socket = null; #endif #if UNITY_WEBGL byte[] tmpBuffer = m_socket.Recv(); int count = tmpBuffer.Length; #else byte[] tmpBuffer = new byte[m_socket.Available]; int count = m_socket.Receive(tmpBuffer, 0, tmpBuffer.Length, SocketFlags.None); #endif
  20. 20. Issues to solve • No Thread Support – Game logic: used to run on a thread at a tick of 10 per second. – We had to profile a couple performance issues in Path Finding related to this decoupling.
  21. 21. Threads • Network Thread – Chat and Server communication – Trick is simple: • Remove blocking Socket read • Check every update for something to consume on the WebSocket
  22. 22. Threads • Bundle Loading Thread – Simply removing the thread wasn’t enough:
  23. 23. Threads • Bundle Loading Thread – Trick: • Spread each bundles on different frame to let the browser “breathe” • Spread custom files parsing of each file on a different frame. to let the browser “breathe”
  24. 24. Issues to solve • Rendering optimization – Basic performance was already good. – But large armies/villages struggled – On lower PCs, game could drop at 10 fps
  25. 25. Rendering • Custom Batching – Dynamic batching wasn’t great for us – Issues with Shadows, Buildings – We knew what should be rendered and when!
  26. 26. Custom Batching • Solution – We pre-compute a large mesh with everything static at the moment and re-compute only when needed – You get the best of both worlds • Equivalent of static batching but with the freedom to add or remove objects dynamically • You save all CPU needed to batch at every frames!
  27. 27. Issue to solve • Player Preferences - Player Preferences were not working in Firefox within an iFrame - This is going to be fix in FF 43
  28. 28. Player Preferences • Solution - We wrote our own abstraction using localStorage capacity - Only issue with Chromium or some plugin limiting access to it
  29. 29. Issue to solve • Issue with Music • Music was speeding and slowing down as we were scrolling. • We have no music in game today because of it. • Thought it might be fix today!
  30. 30. Issue to solve • Pre-memory allocation – You need to specify beforehand how much memory your game will need. – Recommended value is 512Mb
  31. 31. Issue to solve • Pre-memory allocation – This value was too short for some of our scenarios. – We made it 718Mb -> FAIL. We started to have player having this: The browser could not allocate enough memory for the webgl content
  32. 32. Issue to solve • Pre-memory allocation – The sweet spot for us was 600Mb – Some 32bits browser might still cap it at 512Mb
  33. 33. Issue to solve • Forget about resource folder – Everything in this folder will be downloaded in the initial download – In order to keep our initial download as short as possible, we removed *everything* from resource folder and moved them to Bundles
  34. 34. Issue to solve • Bundles Download – Avoid for now WWW.LoadFromCacheOrDownload – Current implementation uses too much memory and produces lags during bundle decompression – We did not see this with normal WWW request.
  35. 35. Issue to solve • Full Screen Button Issue – We had a weird bug with Full Screen. – Don’t trigger it on MouseUp. Unity swallow the event and doesn’t pass it down to the browser. – Worked for us on MouseDown.
  36. 36. Issue to solve • Debugging – This is a tough one – At least you have the console that provides some high level information – Forget about breakpoint (js file is too big for that)
  37. 37. Debugging • One ugly way: – Open JS file with Sublime Text – Search for the function you want to debug and add alerts within the function. – This helped us on really tricky issues.
  38. 38. TO CONCLUDE
  39. 39. First results • Game was released 3rd of December – Facebook with WebGL only – iOS – Android
  40. 40. First results • Launch Day Results - Monetization – WebGL: $0.6 ARPDU – iOS: $0.44 ARPDU – Android: $0.26 ARPDU
  41. 41. First results • First results - Retention – iOS: 45% D1 – Android: 36% D1 – WebGL: 27% D1
  42. 42. Future • What’s next? – Hybrid version WebGL/WebPlayer – User Acquisition
  43. 43. THANK YOU Vincent Vergonjeanne Twitter: @vvergon Email: vincent@everydayiplay.com

×