[socialist_coder]

You guys are not understanding this at all. Flash and Unity webplayer plugins are being blocked by browsers now. Flash still works for the most part, but Unity doesn't. Facebook is losing game players because of this, and new games are being built in Unity and not Flash, so it's harder for them to launch on Facebook.

This solves that problem by letting you compile your game for Facebook Gameroom straight from the Unity editor, and supports the Unity in app purchase plugin. So now that mobile game that you just built can easily launch on Facebook too with very little effort.

https://developers.facebook.com/blog/post/2016/11/01/unity-e...

Html5 / WebGL is not an option. It's super super slow and doesn't even work for half your players. Until web assembly is live and has good adoption, this Facebook Gameroom thing is going to be the best bet for launching your Unity game on Facebook.

Big studios can afford to develop Flash versions of their Unity mobile games just for Facebook, but small studios can't. So this is also great for that, to level the playing field a bit.

Edit: I'm actually fairly excited about this. We have a bunch of Unity mobile games out there but have launched none of them on Facebook because of the bullshit with the webplayer plugin and how terrible the WebGL stuff is right now. Now we can finally launch on Facebook! This is awesome for small Unity studios. Very very awesome.

I can also say with good confidence that not many people commenting are the target market here. You already have steam installed and you play games through that? Probably not the target market. If you play a ton of freemium games on your phone and/or you used to play freemium Flash games on Facebook - you are the demographic for Gameroom.

[rubber_duck]

>Html5 / WebGL is not an option. It's super super slow and doesn't even work for half your players.

Any sources for this ? I know that WebGL adds overhead but for the simplistic kind of games (your run of the mill Unity games) you should have no trouble staying above 30 FPS, especially if you're smart about it and optimize to reduce draw calls. I would assume that most PCs out there have WebGL support by now (at least over 70%) considering how low the requirements are

>Until web assembly is live and has good adoption

I don't see how WebAssembly helps much - it primarily reduces the load time and download size with the binary encoding - but you can get similar levels of perf with ASM.JS and you still need to go trough same WebGL API as the DOM.

[vertex-four]

I've never been able to play a Unity/Unreal game compiled to HTML5, on a fairly beefy laptop which generally runs desktop games alright. Pure HTML5 games tend to work for me, but there's no real "game engine" for them along the same lines as Unity/Unreal, which many current mobile game developers use.

[daredevildave]

>"but there's no real "game engine" for them along the same lines as Unity/Unreal"

https://playcanvas.com/

[EJTH]

Is that beefed up laptop by any chance a MBP ? Those have issues with WebGL mainly because of the retarded default pixelratio on it.

[socialist_coder]

> I don't see how WebAssembly helps much - it primarily reduces the load time and download size with the binary encoding

This is the slowness I'm talking about. I should have been more clear. I did not mean slow frame rate, I meant abysmally slow loading times. The frame rate is actually fine, its just the loading time that makes it a non starter.

If you have a mobile game in Unity, you've already done the optimization to make it run at a good framerate in webGL on lower end hardware.

[rubber_duck]

That's because big engines are filled with stuff that 90% of the games won't use (ie. they wouldn't care if it wasn't there) but because it's a general purpose engine it needs to implement all that and be flexible in the implementation, and the dead code elimination can't do the magic because most of it is runtime driven.

You can still use something smaller/purpose built and compile to ASM.JS and it runs just fine - I rolled my own scenegraph for a visualization app in C++ - it compiled down to ~120kb of gzipped ASM.JS if I compiled out logging, and it ran on both browsers and mobile, it was even loading and rendering fast enough (~30 FPS) on mobile browsers on low end phones (eg. Mali 450GPU, some old quad core mediatek chip) with shadow mapping.

[socialist_coder]

You're definitely right about the feature bloat in Unity. We are probably only using 10% of the features, but like you said, we're still stuck with all that code. It must be a hard enough problem to solve that they didn't want to try and go down that route. Unity isn't dumb, I feel like they would go down that path if they felt it would be successful and was worth it.

> You can still use something smaller/purpose built

One of the advantages of using Unity though is that you don't have to write your game multiple times. Large studios can afford to do that, and they do. But for small studios, the ROI on porting your game to the web is not even close to positive, so hardly anyone does it.

[rubber_duck]

>One of the advantages of using Unity though is that you don't have to write your game multiple times. Large studios can afford to do that, and they do. But for small studios, the ROI on porting your game to the web is not even close to positive, so hardly anyone does it.

But once you have C++ code base with OpenGL ES 2 you're basically "web ready" - porting is pretty straightforward with emscripten. The only porting is what you would have to do with an engine anyway (input/gameplay changes for web)

[daredevildave]

Please don't associate WebGL being bad with Unity being bad at exporting to WebGL...

PlayCanvas is generating WebGL games that run on mobile and download in only a few megabytes. You can generate great WebGL games today.

[throwaway2048]

that doesn't solve the problem that webGL is both very slow, and is completely nonfunctional for a large amount of users.

https://www.khronos.org/webgl/wiki/BlacklistsAndWhitelists

[daredevildave]

Define large? You need a graphics driver more recent than Jan 1, 2009.

And slow compared to what? Flash? Canvas 2D?

[throwaway2048]

lots of systems are that vintage or older, and do not have update-able graphics drivers due to being laptop OEM specific stuff (this was the case for all nvidia/ati mobile chips until recently, the OEM provided the driver, generic nvidia/ati drivers cannot be installed).

[NTripleOne]

Compared to the unity browser plugin or a native executable.

[socialist_coder]

Unity has basically said that they will not be able to make a good WebGL export until something like web assembly exists. It's just not possible. The entire Unity game engine + your game code compiled to javascript is too much for browsers to load in any reasonable time frame if you have to use plain javascript.

https://forum.unity3d.com/threads/webgl-roadmap.334408/

Memory issues

One of the biggest issues we see people run into with Unity WebGL right now is browsers (especially Chrome) running out of memory on trying to run Unity WebGL content. There are separate issues here:

The need to allocate a continuous block of XXX MB of space for the WebGL content. This is the memory Unity will operate on. The size of this can be configured in the WebGL Player settings. This needs to be large enough to fit all the objects and assets Unity will have loaded at a specific point in time. You can use the Memory Profiler in Unity to debug how this space is being used. This needs to be a continuous block of memory in the browser’s heap. If the browser is low on memory, or it’s heap is fragmented, it may fail allocating such a block of memory. Browsers needing too much memory to parse the JavaScript. The JavaScript code emitted by Unity for a WebGL player build is several orders of magnitude larger than other common uses of JavaScript, and JavaScript VMs may require a lot of memory to parse all this code. In particular, Chrome’s V8 sometimes runs into issues with this, causing it to crash, because it cannot allocate enough memory to parse the code. In Firefox, this is not as much of an issue, as Firefox uses asm.js to AOT compile the JavaScript, which has a smaller memory overhead.

For a lot of use cases, this is currently the biggest show-stopping issue on WebGL, and it is not an easy one to fix. Right now, the best we can do on our side is to emit less code. We have been experimenting with this at our last HackWeek, where we had a project to see how far we can reduce the output size of our WebGL export. At the end of the week, we were able to build a simple Unity project to WebGL with a distribution size of 1.2 MB, by improving code stripping, improving compiler settings, and removing things we don’t need among other things. While this value is somewhat theoretical, as some of these improvements were made given assumptions we cannot make in general, we did learn a lot from this week, and I expect to see a lot of changes which benefit build output size to be rolled back into Unity starting with version 5.2. Also, we have build tools to visualize which code modules got included in the build, how much code was generated for those, and what caused them to be included. We plan to make these tools available in a future Unity release (5.3 at earliest), which should greatly help users to analyze and optimize their build output sizes. Reducing code output size also helps a lot with startup times, as it reduces the delay needed to parse the code.

But, ultimately, we expect that these memory issues will be helped much more by advances in browser technology. All browsers are moving towards 64-bit builds, which lets them use larger address spaces. And, more importantly, Mozillla, Google and Microsoft are working on a new technology called WebAssembly which packages asm.js code into a bytecode format, which can then be very efficiently be compiled into native code. We are pretty excited about this, as this will greatly reduce load times, memory overhead and distribution size of WebGL content.

[jay_kyburz]

Don't get too excited, there is no discoverability other than what you pay for as far as Im aware.

Steam gives you 1m impressions when you launch, and 2.5m for updates. Not to mention nice exposure in new release section and fairly good search tools.

Gameroom has none of this.

[NTripleOne]

>and 2.5m for updates

I'm assuming that's for major (content) updates only, right? Surely they're not giving every joe bloggs developer 2.5m free views because they fixed some minor bugs?

[shakna]

> Html5 / WebGL is not an option. It's super super slow and doesn't even work for half your players.

Really?

What about BrowserQuest? [0]

It works on my Surface RT, my crappy Android phone, hell its snappy running in Safari!

The limiting factor is WebSocket support, not HTML5. Canvas is more than good enough for complex games.

Unity's issue is that they never had a decent way of exporting to web, and now the architecture is more rigid, they're screwed.

But for game engines that work nicely, you have:

* Phaser [1] - Canvas & webGL * Pixie.js [2] - webGL with Canvas fallback (Check the gallery!)

Babylon.js would have made the list, but it is slow for me - which tells me that the implementation of the framework can be bad. Not that the technology is slow, as Pixie is blisteringly fast.

If I wanted to build a 3D for Facebook's market tomorrow, I'd choose Pixie.js. Not Unity. It'd be built as fast, and it'd run faster.

Unity is great for the desktop. They haven't conquered the web - their engine is just unsuitable. wasm isn't a solution for that, its just a stopgap.

[0] http://browserquest.mozilla.org/ [1] http://phaser.io/ [2] https://github.com/pixijs/pixi.js

[socialist_coder]

You're comparing apples to oranges. Those javascript engines are just not as good as Unity. They have a fraction of the features and size of community.

Also, you're looking at the problem from the wrong angle. We aren't trying to build a game for the web. We're trying to build a game for mobile first, and then whatever platforms we can target outside of that is a bonus. We can't make sacrifices and use an inferior engine just because it does web builds better. Mobile is where the vast majority of the money is, not web.

If we were trying to build a game that ran equally well on the web and mobile, then sure, going with one of those javascript engines would be the way to go. But that just isn't the nature of the game industry right now. Most of the games using the javascript game engines are advergames or hobby projects or tech demos.

[shakna]

Now you're comparing something different.

I pointed out that webGL and Canvas can be good enough, not that it has feature completeness against Unity, or the same development adoption.

For the platform, we're talking about Facebook here. Web-first development makes sense. Web to app is trivial, and how things like Cordova work.

The engine may not be as featured, but it has everything a Facebook style game needs.

Particles, 2D physics, 2.5d rendering, raytracing for 3d.

Unity is just never going to run correctly within the web browser. They admit it, and the knowledge that the web player would break has been on the horizon a while.

I wouldn't say I'm looking at the platform the wrong way - I'd say the industry is. If you want web at all, you need to deal with JavaScript and its idiosyncrasies right off the bat.

At the end of the day, the company who can still embed their game is going to have a competitive advantage.

[herbst]

I always had the impression that webgl games run way smoother than unity games on chrome/ubuntu.

[zelias]

This perspective actually made sense of this release for me

[ungzd]

WebGL is sufficient for 3D buildings in Google Maps but insufficient for Facebook's clash-of-three-in-a-rows?

[socialist_coder]

The issue we were having with Unity's webGL exporter is that you would end up with tens of megabytes of javascript code (the entire unity 3d engine in javascript, plus all your game code!), not to mention your assets. So you get a fairly large download, and then your browser spends tens of seconds loading and parsing the javascript, if it even loaded without errors.

This is for an app that loads in 5 seconds on an iPhone 5.

And remember, the target demographic for Facebook games is mostly people with lower end hardware and not cutting edge browsers. So they probably wont have asm.js support, and the loading will be even slower for them on their older hardware.