| > 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 |
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.