Mozilla Games Technology Roadmap(blog.mozilla.org)
blog.mozilla.org
Mozilla Games Technology Roadmap
https://blog.mozilla.org/futurereleases/2015/07/02/mozilla-games-technology-roadmap/
12 comments
I think the "new APIs only on https" plan has exceptions for lan-local addresses or at least for localhost.
that doesn't help. The phones don't connect to localhost they connect to a PC
user overrides are also an option: http://www.w3.org/TR/powerful-features/#development-environm...
That's not really a solution either. You really expect your house guests or people visiting a museum or event to do a technical reconfiguring of their phone just to interact with the installation or game?
I would think that museum should be able to get a SSL cert.
But yeah, "SSL-only" kinda breaks the end-to-end principle since we have no mechanism to assign SSL certs to endpoints on demand. So it seems flawed on a conceptual level.
But yeah, "SSL-only" kinda breaks the end-to-end principle since we have no mechanism to assign SSL certs to endpoints on demand. So it seems flawed on a conceptual level.
Most of these types of exhibits are created by art students and shown at events and happen to be run by museums. Neither the students nor anyone at the museum have any tech experience whatsoever. As the system is now it works for them. But when HTTPS is required they'll all be S.O.L.
I think it's feasible to have a domain with certificate for resolving any ip, using dnsmasq as DNS resolver for that domain, combining this
https://pfigue.github.io/blog/2013/12/06/configuring-dnsmasq... (but without --server)
and this
https://stackoverflow.com/questions/28204678/dns-service-to-... (specifically, the "synth-domain" parameter, maybe limiting it to LAN ip addresses)
I haven't tried it.
https://pfigue.github.io/blog/2013/12/06/configuring-dnsmasq... (but without --server)
and this
https://stackoverflow.com/questions/28204678/dns-service-to-... (specifically, the "synth-domain" parameter, maybe limiting it to LAN ip addresses)
I haven't tried it.
I'm not really sure how that would help. Wouldn't all the phones be getting their DNS from the local router? How would that work without having each users have to configure DNS on their phones? Also how does running DNS server help? I don't expect people to know how to configure their router to point to some DNS server running on their local PC. Maybe I'm mis-understanding the suggested solution
The application redirects to <local https host>, and to make the certificate valid, have a wildcard *.example.com. With the DNS server you can have e.g. https://192-168-0-7.example.com/ resolve to 192.168.0.7.
All of this, of course, only if there are some desired HTTPS-only features in the browser.
All of this, of course, only if there are some desired HTTPS-only features in the browser.
Couldn't you host over HTTPS locally with a self-signed certificate? I've done it with my own, similar, locally hosted stuff.
That would require users to install his cert as trusted, though.
Ah, right, and I forgot how much the mobile browsers' UIs suck for this. On desktop it's just "yeah, I know what I'm doing <click>". On mobile they invoke threats and hide everything under barely visible links.
It's a pain, and I've yet to find any good guides. I'm actually in a fix right now because I want to develop over localhost, but need this Flask site to work on HTTPS. I'm sure it's possible, but I have yet to find any guides or examples that make it straightforward. I love that we're moving towards security, but I wish it was easier...
It also requires people to buy a domain before they can host a website. This is already a bad idea, and it makes even less sense as IPv6 deployment picks up and more people use clever IPv6 addresses instead of hostnames.
[deleted]
> Improve browser storage capabilities.
I wonder why local storage even is a thing.
It doesn't interface nicely with facilities provided by host OS.
Providing file IO to a fenced-off, per-origin part of the filesystem would allow people to roll their own data serialization and allow users and desktop applications to drop in/pull out files as they desire.
I wonder why local storage even is a thing.
It doesn't interface nicely with facilities provided by host OS.
Providing file IO to a fenced-off, per-origin part of the filesystem would allow people to roll their own data serialization and allow users and desktop applications to drop in/pull out files as they desire.
I wonder what they mean by scalable source maps? The last time they proposed an alternative to source maps they basically proposed shipping down an AST structure which was even larger. Current source maps already tax the debugger for large programs, so much so that for GWT we had to implement optimizations in the source map generator to avoid generating nodes that are not helpful for debugging but which cause bloat.
This all sounds great, but I didn't see anything about simple HTML5 Canvas performance. Firefox is in dead last when it comes to the 2d rendering performance. I can run our HTML5 games at a smooth 60 FPS on Chrome, Safari, Opera and IE, but only get 10-15 FPS on Firefox on the same computer.
Can you please report a bug with a link to the page showing the problem? Add ":bz" to the cc list for the bug and I'll make sure it gets looked at.
it's probably a bug, you should report it along with OS and hardware details
It is not related to a specific platform, we've tested on many different computers and operating systems. We also get reports from users all the time saying the game is barely playable on Firefox but works great on any other browser they use.
Is this a particular GoldFire game? Can you share a link?
Yes, it is http://casinorpg.com (the rest of our games don't use canvas).
Hey, I've been trying to look into this a bit. Which OS (or OSes?) do you see 10-15fps on? Because so far on Mac I'm not seeing any differences compared to Chrome, but I may just be missing it...
My main OS is OS X and this is where I've done the most testing, but we see similar performance degradation on Windows as well. We've tested on multiple Macs and Windows machines. It is almost as if no hardware acceleration is being used.
Thanks. I'll take a look.
Firefox generally uses the same 2D vector APIs as the native host system for canvas (in particular, D2D on Windows). So this sounds like some kind of (possibly platform-specific?) bug.
Side question, but is there a way to package content with Firefox as a desktop app (like node-webkit/nwjs does with Chromium)?
Seems to me that one nice feature for HTML gaming is the ability to deploy a paid version to Steam/GOG/etc..
Seems to me that one nice feature for HTML gaming is the ability to deploy a paid version to Steam/GOG/etc..
Yes, it's part of the OpenWebApps[1] initative. As far as I know, however, there's no standard way to package them up with the runtime for shipping[2], except for XUL Runner (which does not target OpenWebApps). For Android, there's an APK packager[3][4].
[1] https://developer.mozilla.org/en-US/Apps/Quickstart/Build/In... [2] There's none for Webkit/Chromium either, as nwjs/atom-shell are third-party projects. [3] https://developer.mozilla.org/de/Marketplace/Options/Open_we... [4] https://github.com/mozilla/apk-factory-service
[1] https://developer.mozilla.org/en-US/Apps/Quickstart/Build/In... [2] There's none for Webkit/Chromium either, as nwjs/atom-shell are third-party projects. [3] https://developer.mozilla.org/de/Marketplace/Options/Open_we... [4] https://github.com/mozilla/apk-factory-service
This is wonderful news. When this takes hold (and assuming the driver situation improves), I'll be able to finally get rid of my home Windows game machine in favor of GNU/Linux.
WebAssembly? We got rid of Flash for that?
Also, is there really that much demand for games in the browser? If you'd like to see a few thousand bad ones, go to "newgrounds.com".
Also, is there really that much demand for games in the browser? If you'd like to see a few thousand bad ones, go to "newgrounds.com".
I hope not everyone is this short sited.
What are the plans for shipping 64 bit Firefox? I see they have Nightlies, but what about release?
64-bit Firefox is available in the Beta channel. It may "soft launch" in Firefox 40, but some features are still incomplete (like NPAPI plugin support).
https://wiki.mozilla.org/Firefox/win64
https://wiki.mozilla.org/Firefox/win64
I thought 'Games' was a verb and thought how does one game a roadmap?
This is awesome :)
One of the things Mozilla could do is to make Flash run better.
My wife prefers Chrome to Firefox purely because Flash tends to stutter more on Firefox, and she plays a lot of Facebook games.
My wife prefers Chrome to Firefox purely because Flash tends to stutter more on Firefox, and she plays a lot of Facebook games.
One of the things Mozilla could do is to make Flash run better.
One of the few things Mozilla CANNOT do is to make Flash run better. Flash is closed source, proprietary software, owned by Adobe. Google did their own implementation (of at least the browser interface + sandbox), I supposed after signing plenty of NDA and handing money over. That's not something Mozilla can (or should) do as an open source project.
Whatever plans you will go looking for at Mozilla, you'll never find "improve Flash" in one of them, even as an option. It just isn't possible. It's like asking Mozilla to make Office run better.
They've offered Shumway as an interdependent re-implementation, but I'm guessing it has tons of compatibility issues as Flash isn't a standard.
You're probably better off just uninstalling Flash in Firefox, to be honest.
One of the few things Mozilla CANNOT do is to make Flash run better. Flash is closed source, proprietary software, owned by Adobe. Google did their own implementation (of at least the browser interface + sandbox), I supposed after signing plenty of NDA and handing money over. That's not something Mozilla can (or should) do as an open source project.
Whatever plans you will go looking for at Mozilla, you'll never find "improve Flash" in one of them, even as an option. It just isn't possible. It's like asking Mozilla to make Office run better.
They've offered Shumway as an interdependent re-implementation, but I'm guessing it has tons of compatibility issues as Flash isn't a standard.
You're probably better off just uninstalling Flash in Firefox, to be honest.
On the contrary, "improve Flash" is part of Mozilla's projects to reduce Flash and plugin problems in Firefox. (I'm a program manager at Mozilla coordinating some of this work. :)
We work with Adobe to identify and fix Flash crashes collected by Firefox's crash reporter. We've made NPAPI plugin initialization asynchronous to avoid Flash blocking page load. We're also prototyping a new plugin sandbox to replace Adobe's Flash sandbox (which is based on an outdated fork of the Chromium sandbox).
Here is more information about some of the plugin work:
https://wiki.mozilla.org/Flash
We work with Adobe to identify and fix Flash crashes collected by Firefox's crash reporter. We've made NPAPI plugin initialization asynchronous to avoid Flash blocking page load. We're also prototyping a new plugin sandbox to replace Adobe's Flash sandbox (which is based on an outdated fork of the Chromium sandbox).
Here is more information about some of the plugin work:
https://wiki.mozilla.org/Flash
Flash runs better in Chrome than it does in Firefox.
Therefore, either the Flash people are deliberately detecting that it's being run in Firefox and slowing it down, or Firefox is doing _something_ which has made it stutter intermittently on every PC that my wife plays Facebook games on.
Would you care to hazard a guess as to what might be going on?
Therefore, either the Flash people are deliberately detecting that it's being run in Firefox and slowing it down, or Firefox is doing _something_ which has made it stutter intermittently on every PC that my wife plays Facebook games on.
Would you care to hazard a guess as to what might be going on?
Chrome maintains their own build of Flash (presumably after an agreement with Adobe).
Firefox doesn't. It also doesn't update flash for you, you need to do that.
That's the difference.
Firefox doesn't. It also doesn't update flash for you, you need to do that.
That's the difference.
Google is essentially maintaining Flash for Chrome at this point, with the PPAPI port.
Chrome's Flash plugin uses Google's Pepper plugin API (PPAPI) instead of NPAPI. So Google can more tightly integrate Flash and Chrome. I've heard from someone familiar with the code that Google's Flash "uses 110% of the documented Pepper API", meaning there is lots of undocumented or underspecified details.
The whole point is to replace Flash with a better alternative.
Or to put it another way: they want to turn normal web pages into Flash sites.
The only reason flash is blockable is because other web technologies, primarily open ones, have limited the need for it. If no attempt was made to match the feature sets of closed, single vendor plugins like flash, realplayer, QuickTime, ActiveX etc, then the majority of the webapps and media sites would be made using those tools. I think the same is true for games now. Do you really want every game engine developer to have their own plugin, with all the security vulnerabilities that will entail?
No, because we already have native and the browser should be left alone for interactive documents.
I think that's a separate problem. We've already crossed the rubicon on having "active" content on the web. A valid concern, nonetheless.
I wish that alternative was confined to a plugin running in a rectangle on the page. Otherwise game theory incentives make every site add a megabyte of JavaScript to every article, and stop you from reading unless you load the whole megabyte.
That's happening today (just check the "big" news sites) just as it happened before with Flash-based sites.
But that is just bad habit of programmers, not the issue with the technology per se.
But that is just bad habit of programmers, not the issue with the technology per se.
Non-essential Javascript is usually added to the bottom of the page, or set to async to prevent it from blocking page loading.
It's disappointing to me that it's 2015 and we have yet to have a good solution for browser games. Flash is still your best choice by a huge margin.
4 years ago I was very bullish on HTML5. Flash was dying, HTML5 was the future! It was right around the corner! I think a lot of people agreed with me.
4 years later - what has changed? Decent webGL support but still driven by a terribly slow javascript runtime. ASM.js gets us halfway there but it's brittle and does't even run in Chrome so it's basically worthless for anything that isn't a tech demo. The audio API is also still very limited.
We've been trying to port our Unity mobile app to webGL for 6 months now and it's been nothing but pain. In hindsight, it was a mistake. I was bullish on HTML5 back in 2011 and I was bullish on webGL in 2014. I was wrong, again.
So, I'd like to have faith in these efforts, but as they say, "Fool me once, shame on you. Fool me twice, shame on me."
4 years ago I was very bullish on HTML5. Flash was dying, HTML5 was the future! It was right around the corner! I think a lot of people agreed with me.
4 years later - what has changed? Decent webGL support but still driven by a terribly slow javascript runtime. ASM.js gets us halfway there but it's brittle and does't even run in Chrome so it's basically worthless for anything that isn't a tech demo. The audio API is also still very limited.
We've been trying to port our Unity mobile app to webGL for 6 months now and it's been nothing but pain. In hindsight, it was a mistake. I was bullish on HTML5 back in 2011 and I was bullish on webGL in 2014. I was wrong, again.
So, I'd like to have faith in these efforts, but as they say, "Fool me once, shame on you. Fool me twice, shame on me."
There's a little bit of misinformation there!
First off, HTML5 has come a long way – there are still areas that need work, but generally I've seen lots of great HTML5 games and the field has improved remarkably in the past 4 years.
WebGL support is now cross-browser. The JavaScript runtime is not terribly slow, and I don't know if you're a bit confused about ASM.js – it does run in Chrome, and pretty well too. However, it's likely to be displaced by WebAssembly going forward, if I understand correctly, and that will be cross-platform and cross-browser.
It'll take a little while, but we're on the way there! Unity's HTML5 examples are pretty good – http://beta.unity3d.com/jonas/AngryBots/ for example looks great and runs well.
First off, HTML5 has come a long way – there are still areas that need work, but generally I've seen lots of great HTML5 games and the field has improved remarkably in the past 4 years.
WebGL support is now cross-browser. The JavaScript runtime is not terribly slow, and I don't know if you're a bit confused about ASM.js – it does run in Chrome, and pretty well too. However, it's likely to be displaced by WebAssembly going forward, if I understand correctly, and that will be cross-platform and cross-browser.
It'll take a little while, but we're on the way there! Unity's HTML5 examples are pretty good – http://beta.unity3d.com/jonas/AngryBots/ for example looks great and runs well.
> I've seen lots of great HTML5 games and the field has improved remarkably in the past 4 years.
HTML5 has come a long way, but I'm talking specifically about non-trivial games. For that, it's quite difficult to use it in a "we are going to make money with this!" way. I have seen some success with people writing their whole game from scratch to work within the very limited scope of HTML5, but most of the time those games are still pretty simple. Even so, I will concede that maybe this statement is geared more towards people trying to do cross platform stuff.
> ASM.js – it does run in Chrome
ASM.js runs in Chrome but it's not accelerated like it is in Firefox, that's what I mean. I was not speaking literally.
> http://beta.unity3d.com/jonas/AngryBots/ for example looks great and runs well.
That's a demo. It does not demonstrate the problems that real developers with real games and real codebases are having with webGL. For example, it does't do any network communication with a server.
And, this game is tiny. They have 14.5 mb of assets and 4 mb of javascript.
Our game (it's a Slot Machine so it's not like it's super complex) has 23 mb of data and 16 mb of javascript. This is much more realistic. You can't do a whole lot with only 4 mb of javascript.
HTML5 has come a long way, but I'm talking specifically about non-trivial games. For that, it's quite difficult to use it in a "we are going to make money with this!" way. I have seen some success with people writing their whole game from scratch to work within the very limited scope of HTML5, but most of the time those games are still pretty simple. Even so, I will concede that maybe this statement is geared more towards people trying to do cross platform stuff.
> ASM.js – it does run in Chrome
ASM.js runs in Chrome but it's not accelerated like it is in Firefox, that's what I mean. I was not speaking literally.
> http://beta.unity3d.com/jonas/AngryBots/ for example looks great and runs well.
That's a demo. It does not demonstrate the problems that real developers with real games and real codebases are having with webGL. For example, it does't do any network communication with a server.
And, this game is tiny. They have 14.5 mb of assets and 4 mb of javascript.
Our game (it's a Slot Machine so it's not like it's super complex) has 23 mb of data and 16 mb of javascript. This is much more realistic. You can't do a whole lot with only 4 mb of javascript.
Outside of games by Unity my personal experience for "Cross-Browser" JS game frameworks has been highly negative. I wanted to try making simple games with JS but most / all the frameworks demos I tried out didn't seem to work on "all" browsers. It wasn't a lag issue, the biggest thing was just getting it to become responsive to my keyboard, you'd think that would be trivial right / not considered an issue "in 2015"? Guess not.
We'll probably have to wait a few more years until Webassembly and the easier to use and faster Vulkan API comes to the browser as well.
I know they've been working on WebGL 2 (OpenGL ES 3.0-based) for a while, but if it doesn't ship within a year, they might as well scrap it in favor of a Vulkan-based API.
I know they've been working on WebGL 2 (OpenGL ES 3.0-based) for a while, but if it doesn't ship within a year, they might as well scrap it in favor of a Vulkan-based API.
> We'll probably have to wait a few more years until Webassembly
I agree, so in the meantime what do we do?
I agree, so in the meantime what do we do?
asm.js + WebGL
WebGL/OpenGL and Vulkan operate at different levels. I suspect that OpenGl and Vulkan will co-exist and it is likely that WebGL and a web Vulkan-equivalent will also co-exist.
It sounds like your main problem is your reliance Unity's WebGL exporter not Asm.js and WebGL.
The other thing that really sucks right now for game developers is that Chrome has disabled its NPAPI plugin support so you can't rely on the Unity webplayer anymore either.
As the CTO of a mobile/web game startup (using Unity), I'm really struggling on what to do here. We have been trying to launch on Facebook Canvas since late 2014 and so far the finish line isn't even in sight.
As the CTO of a mobile/web game startup (using Unity), I'm really struggling on what to do here. We have been trying to launch on Facebook Canvas since late 2014 and so far the finish line isn't even in sight.
I'm not very familiar with Unity but doesn't it support real HTML5?
[deleted]
Browsers are quite capable with HTML5 and WebGL these days. We've built an entire MMO with hundreds of thousands of lines of hard-coded Javascript that runs fantastically for tens of thousands of users (most players don't even know it isn't flash). You can take a look at it at http://casinorpg.com.
Ignore Unity webgl and try PlayCanvas instead? It's a lot more work to port, but you'll get much better performance.
http://docs.happyfuntimes.net
Either that or please suggest a viable workaround