[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)