Mozilla and Unity Bring Unity Game Engine to WebGL | Hacker News Reader

Mozilla and Unity Bring Unity Game Engine to WebGL

blog.mozilla.org

325 pointsrobin_reala116 comments

I do like Unity (especially the component/entity system) but recently I've been enjoying making games in plain ol' JavaScript (2, and 2.5D - granted). Everything is just so open: I don't obfuscate or hide anything, and it's all available via "view source". With an inspector/console you can quickly see how stuff works and start messing around with it.

Of course, 99.99% of people just want to play games - but the way I got interested in coding was by hitting RUN/STOP on C64 Basic game, tweaking the values, and seeing what happened.

Pushing proprietary file formats through asm.js is a neat trick and gives amazing results with little effort. But the long-and-potentially-boring "learn yourself webgl for real" route seems more "web". And if someone, someday, gets into game or web dev by trying to cheat at my games (the same way I did, back in the day) - that would be flippin' awesome!

Depends on what you want. If you want to achieve the same results that are possible with Unity, you would need to use some more complex opensource engines like Turbulenz and would be restricted to WebGL for now. Rolling your own engine doesn't make sense other than learning and maybe for simple 2D stuff.

If you want to create games in a very efficient way and have a quick time to market supporting a lot of different platforms, there is hardly a way around Unity now.

You're a dying breed my friend. Most software developers, game developers including, have no appreciation for the technical aspects of their field, and no appreciation for the importance of thoroughly learning and understanding the foundations on which their patchy work is standing - they're glorified product managers and all they care about is the end product they can make a quick buck off of until it's superseded by another, not how well-crafted it is.

Going from OpenGL to a game engine with a modern lighting and rendering pipeline, physics, an editor, etc. is a huge amount of work, though. It's worth knowing how it all works and being able to write parts from scratch, especially since what's in a game engine is nowhere near satisfying every use case, but there is also no shame in using a preexisting game engine; if programming and (in the case of a one-man show) designing assets for a game is going to take a lot of time as it is, getting bogged down in game engines would be foolish.

Yes, this is why Unity is so popular.

Using unity or a similar game engine has absolutely nothing to do with how "well crafted" your game is, nor does it tell if the developer wants to make a "quick buck".

I'm all for learning how stuff works and for taking pride in doing things well (showing appreciation for the craft, as you say), but how many people do you see making their own web framework to develop a web app? Maybe it makes sense in some cases, which is true for games as well. And it is even more true if your purpose is to learn, or to make something in a different way from established frameworks.

We stand on the shoulders of giants in lots and lots of ways, and we should make the most of it to continue to build great stuff (games, or anything else).

With that said, I stand by the opinion that knowing how the low-level stuff works makes you, if nothing else, more capable of using the higher-level stuff. We just need to choose the best way of doing what we want to do, with the time, money and tools we have :)

Unity is not a "file format". It's a tool and development environment that reads and writes and edits lots of different "file formats", for which programmers can make runtime and editor components, that artist and level designers who don't know how to program can plug together and configure. And it can create applications for a wide range of different platforms, not just asm.js/WebGL.

It's nice that you're happy coding things up in JavaScript and WebGL just for the web browser, but Unity has a much wider scope than that.

Eventually somebody will write something like Unity that runs entirely in the web browser, and figure out how to make it target all the different platforms that Unity does (once Apple has their brain tumor removed and supports WebGL in their iOS browser for use in anything other than advertisements). But right now there is nothing like it for web development, and it brings a lot to the table that many people really need.

This is HUGE news if it performs as well as advertised. We have been creating games in Unity for a couple years and eyeing HTML5 as a possibility that just was never capable enough to trust with a major project.

Unity as a development platform is a joy to use, and now we won't have to have the same "Unity plugin or messy HTML5 game?" conversation for every new project.

Yeah, I stalled with my plain 'ol Javascript games after the Unreal Engine demos, since I assumed it'd just be a matter of time before Unity got a plugin-less web export.

Very exciting. This is a great way to get people playing your game without worrying about plugins. It will be interesting to compare the weight of a basic 2D game using Unity 4.3 2D engine to one written in a HTML5 framework such as Impact. I'm sure the use case is more for 3D gaming on WebGL, but using one toolkit for all development is definitely easier for the developer.

Regardless, this is great news and great trend. Corona SDK also announced WebGL support is coming soon [http://coronalabs.com/blog/2014/03/07/coronacards-is-cool-he...]. Lots of great new tools to play with.

Is there an straightforward way to solve the issue with crazy load times on big WebGL games? If I remember correctly, I played one a while ago and it had to download assets for ten minutes before I could play it and it was a huge downer. If this becomes the norm I'm sure it wouldn't be too hard to get used to, but I was coming at this game from the mindset of playing instant gratification flash games.

It would be cool if the engine could figure out what assets to download on-the-fly, but I have a feeling that's not the case so game makers would still have to do a bit of work before making the games web-ready (instead of ideally just hitting an "export to webgl" button).

If it becomes popular I'm absolutely certain those types of techniques will be developed. Just as with the XBox One and it's ability to let you start a game that it's still downloading

You can read/write local files from within a webpage. So I guess its possible. It would require looking into how WebGL loads assets and overriding this with diskIO operations not difficult.

The next problem would be asset management, but this isn't an important issue. A lot of game data is already stored locally with little to no protection.

I'd have to look at how javascript handles file I/O it might not be 'that' difficult.

There's localStorage and there's IndexedDB. The former is blocking and not ideal, but I think you can store blobs in IndexedDB and it's async.

It depends. I was talking about storing files in user-land not browser-land, like c:\program files (x86)\company\our cool game\art\texture.png

That can handled currently in HTML5. Even written too if you give it permission on load. This would side step warnings of IndexDB going over 50MB would be easier with large textures/models. Also side steps that webworkers can't really do asynch indexDB stuff.

I'm not a web developer at all. I'm just researching this as I type it.

Oh, for local apps? Sure, you can do that. file:// doesn't work well though (you can't load textures from it, for example), but you could use a local server.

The problem is that most people don't have a local server. Even if you have local (geographical nodes) your still limited to the clients bandwidth.

Also how can you load say models but not textures? All files are just binary data.

I guess your only option is to play around with indexDB. Also it that per file 50MB, or overall 50MB. I guess with more aggressive compression could could achieve decently small disk usage.

>Also how can you load say models but not textures? All files are just binary data.

CORS and the Same Origin Policy.

If you read thought my comment history you'll see I'm not a web developer.

dont worry CORS or same origin policity have nothing to do with the way the server should load assets.Not sure why the other guy talked about that. The issue you raised still stands.

What? Loading of WebGL textures is subject to the same origin policy.

You can load WebGL texture from byte[] pixel array. http://stackoverflow.com/questions/9046643/webgl-create-text...

You missed the Filesystem API

https://developer.mozilla.org/en-US/docs/WebGuide/API/File_S...

That's a new one to me. Sounds awesome!

In Unitys case they already had a concept called AssetBundles that allowed you to launch an initial small loader scene and show something while downloading other Bundles in the background. If they port that concept to HTML5 it should be pretty easy to implement on demand loading..

I think Unity can distribute their runtime library via CDN (just like three.min.js or something). It will able to cut down the initial some megabytes.

Progressive downloading technique (like AssetBundle) is a must for both loading time and server costs. Every developer should use it because if many games have massive long loading time (like Epic Citadel or BananaBread or Monster Madness. Whatever Mozilla says, these demos are not commercial ready), end-users will hesitate to click game links. I feel many gamers already stopped considering the web as a game platform these days. Kids know how to download games from App Store, but they don't know how to use Mobile Safari. All App Store, Google Play and Steam are growing. Many users will continue to prefer download apps for a long time.

Ultimately, time may solve the problem. The internet bandwidth is growing 50% per year. Many PC browser games will start instantly 5 or 10 years later, Mobile will have more trouble.

Html5 appcache will download and cache resources indefinitely, and supports differential updates, but it's somewhat of a pain to work with and there are some browser-specific constraints on how big it can get. Using gz compression the size of the assets shouldn't be that much bigger than downloading a desktop game (which also takes a while).

People forget that modern 3D games take up huge amounts of storage space. Meshes, textures, maps, and sound recordings aren't cheap.

You could mitigate this by asynchronously loading certain files, or outright designing a game to be quickly downloadable (for example, by using an art style that uses only shading and mesh coloration instead of textures, or by going all demoscene and procedurally generating everything), but for anything resembling a modern "AAA" game, a long download time is probably unavoidable.

That's why webapps are built in a modular way: it's similar to 3D games in the sense that you don't need to have everything immediately to start using it: load what you need to display first, and get the rest when needed: e.g. you don't need the last level of a game when you're just starting it.

Actually, I was toying lately with the idea of making my own modules loader * insert mandatory xkcd strip about competing standards * because I wanted an hybrid loader that can pack multiple modules per file, but that doesn't have to have all modules in a single file either (e.g. 3d models could be packed with their textures, or levels packed with the models they need) as I haven't come up with a satisfactory setup to do so in r.js or browserify yet, however Unity already solved that issue in its Web Player, so making a JS version of it should be trivial.

Update: I'm actually having high hopes for webpack as it seems to combine the strengths of both Browserify and RequireJS, and seems tweakable to package modules into a couple of files. I'm not sure why it's way less popular on Github though.

You could display a much smaller web game while the main game loads. The trick is finding that proper balance where people are entertained long enough for the real game to load, but not so much that they'll want to keep playing the loading game afterwards. I, for one, can't wait to be waiting for a loading bar for a loading game to play while the main game loads.

Or how about this: Game Loading Lobby MMO, where you can hang out and chat with everyone waiting for their real game to load - IN 3D!. Maybe you can break out the character builder and have people do that, then get dumped into the MMO lobby while they wait for game assets to load.

Or you can just put a reddit iframe above the loading bar and call it a wrap.

Mozilla, please stop promoting nonfree software. It would be better to assist in the creation of a free game engine for the web instead of Unity.

I am a FOSS advocate as well, but I disagree that this announcement is a bad thing.

First, Mozilla has and does assist in the creation of FOSS game engines and tools (Gladius, CubicVR, help to various web ports like JSMESS and various open source game engines, etc.).

Second, even the LGPL shows that absolute avoidance is not always the best thing to do regarding closed-source code. Reality is more complex. Sometimes interoperability with closed-source code is good for everyone including free software.

In particular, a big benefit for free software here is that Unity games can now run on the web, an open platform. Before they required a proprietary plugin that did not work on Linux or BSD, but as JS+WebGL they can run on those platforms. (Yes, the games are proprietary, but visiting websites using proprietary code is basically unavoidable, both on the client and server-side. At least we can do it using FOSS tools now.) So this helps support free software OSes.

A final point, while the Unity engine is a proprietary codebase, they also have lots of code that is FOSS, see their github page. They are also working with even more open source code for the WebGL port, as it uses emscripten.

>First, Mozilla has and does assist in the creation of FOSS game engines and tools

Parent comment didn't imply the contrary. "stop promoting nonfree software" doesn't mean "stop only promoting nonfree software".

>even the LGPL shows that absolute avoidance is not always the best thing to do regarding closed-source code

If you ask the FSF, the LGPL should really be used as a last resort. Unity is not too common yet (and hopefully will never be as long as it remains proprietary), so I don't see why we should push it forward by helping its integration. Same goes for HTML5's EME. I'd rather have a purely open platform with less features and popularity than a platform with an open base and countless incompatible binary blobs sitting onto it. And even the abomination that EME is would at least be an actual standard.

>Unity engine is a proprietary codebase, they also have lots of code that is FOSS

If you can't build it, it's not worth integrating. The only thing this is good for is making a FOSS alternative (although I guess they keep the important bits secret). I'd be using Google Chrome if "99% open source" was good enough. By using Firefox (though Chromium would be fine if it weren't for the user-hostile features), I precisely want to keep a clean FOSS platform. Conversely, I only use an Android ROM because there's no good alternative, which is not the case for Unity. So I wish they'd keep it out for now.

I get where you're coming from, I think, but Unity is not related to standards in any way, unlike EME. Unity is just another game engine that can now run on the web. All we did here is help them along the way, just like we help other game engines to port to the web. It is not going to become a standard or part of the browser in any way.

Even with Unity (and Unreal and others) porting to the web, web browsers remain open, while web content (what ported Unity is) was always non-open (since practically all websites are not FOSS).

I agree with you on the other hand that EME would in fact be a danger to the openness of the web.

Thanks for your reply.

>Unity is not related to standards in any way

I know, I mentioned it. I believe a standard at least has some practical positive impact, unlike the integration of a particular closed platform.

>web content was always non-open

It's true that obfuscated JavaScript makes, in a way, a closed platform, but much less so, in my belief, than straight-up binary code (which Unity delivers and EME enables).

I get your overall point, but it just seems a slippery slope...

> Unity is not too common yet (and hopefully will never be as long as it remains proprietary)

7 of the top 10 iOS games were developed with Unity, so it is already a really big deal for game developers.

Why ? There is room for both imo. As far as Enduser Tools go, most times the stuff from companies that make money from their product is superior to open source alternatives. Like the Adobe Suite, Autodesk Stuff, various Game engines etc. Of course there are good open source alternatives and it's good that they exist, but it's not the best choice for everyone.

There are only so many projects that Mozilla can take on at once, building a game engine would take resources away from firefox/asm.js etc.

I think you're being far too pessimistic.

First, build the infrastructure to support amazing things. (Asm.JS, WebGL, WebRTC)

Second, encourage people to spend real money developing for it, however they want to. (Unity 5)

Third, the open source competitors come around. (???)

And by then it's too late and becomes painfully difficult to go back.

Examples: Linux, FirefoxOS. On the other hand, no DRM in HTML leads to the platform still being free.

It's easy to integrate proprietary solutions but it's incredibly hard to remove them. IT is way easier to not adopt them in the first place. In that regard, proprietary software is similar to AIDS.

https://github.com/libgdx/libgdx games run on Android, iOS (RoboVM), Desktop (Java), and HTML/WebGL (GWT)

It would be better to assist in the creation of a free game engine for the web

Bananabread? https://developer.mozilla.org/en/demos/detail/bananabread

To be honest: From this point over here this is promotion for Mozilla. I'm a Mozilla fan, Firefox user and welcome news that aren't "This demo only works in Chrome" for once.

I don't see it as a sell-out, I see it as competition to the braindead/insulting 'Upgrade your browser' Google notifications and similar nonsense. A sign that Mozilla is very much alive and innovating.

Is it just me, or it is a bit hypocritical for Mozilla to be talking about the wonders of the Open Web and then embracing two very proprietary developer platforms to promote Asm.js

If they cared about the open web, and they cared about open source, they would be helping open source game engines like Ogre3D and Torque3D.

Instead, for the sake of expedience, we see them promoting proprietary components.

It was not too long ago that they were lecturing the world on the evils of proprietary video and audio.

Is it just me, or it is a bit hypocritical for Mozilla to be talking about the wonders of the Open Web and then embracing two very proprietary developer platforms to promote Asm.js

There is no contradiction here, on the contrary (heh!). Mozilla doesn't believe an Open Web precludes proprietary applications. In fact they've strongly argued that the web should be properly standardized so that it's possible for anyone, including commercial parties, to make clients for it, and that just opening up source code (ala WebKit, PNaCl, etc) does not do this hence is a bad way to achieve an open web.

The point has also already been made that this makes it possible for Unity games to run on open platforms without requiring closed source blobs.

they would be helping open source game engines

Uh, emscripten and asm.js have been enhanced to properly port many open source engines and game libraries long before this one was announced. I'm going to guess Unity was possible because they provided engineering resources to port their own engine.

>Mozilla doesn't believe an Open Web precludes proprietary applications

By definition, it must. It's a slippery slope and it's the reason Mozilla is vehemently against EME. The rest of that line sounds like nonsense to me in that context.

>The point has also already been made that this makes it possible for Unity games to run on open platforms without requiring closed source blobs.

Awesome, the joys of running proprietary software on Linux. Ah, why even have a FOSS OS then? Ditch it and get Windows! /s

See my full answer on this topic here

https://news.ycombinator.com/item?id=7423703

to which I can add that we have in fact helped, and are helping, port open source game engines like Ogre3D and Torque. These things do not preclude each other. (Yes, we all have finite time, but helping all such ports is a major priority.)

Also, it is not just that they do not preclude each other - they benefit each other as well. For example, you can see some pull requests from Unity developers to emscripten, those fixes and improvements then get to all the projects using it, many (most?) of which are open source. The same goes for fixing a bug that Unity hits, that bugfix benefits all other projects too.

From my experience, Mozilla supports anyone who wants to move the web forward. They've been incredibly supportive of our team, and the open source engine that we're building at Verold. The ecosystem needs commercial vendors; what's important is that they're now running on the open web rather than a closed plugin.

This is awesome. I worked in educational technology building virtual humans (http://alelo.com/), and have experience with a variety of game engines. Unity is far and away the most pleasant developer experience, despite being 1/100th the cost of some of the other commercial engines.

Pre-Unity, game engines were truly stuck in the dark ages.

Great announcement. With plugins starting to go away due to browser changes and as a delta to mobile, this was needed. The end of 2014 Chrome will disable plugins that don't use PPAPI and all NPAPI plugins will no longer work (Unity, Silverlight and some other popular ones won't work). So glad they updated it and in the right direction to WebGL.

"This is a big day for evolving the Web as a platform for gaming and we are very excited to see what experiences developers will bring to the Web using this powerful technology."

Slightly off-topic: I wonder if we're going to see more games being written to run in Web Browsers, or more games being written using web technologies like JS + WebGL but for desktop/mobile devices using things like phonegap/node-webkit [0] and then sold through various app stores such as Steam, iOS & Android.

The infrastructure for monetising web games in the same way that Steam and the App Stores has done isn't there yet, but maybe it will be soon?

[0]: Like A Wizard's Lizard http://steamcommunity.com/sharedfiles/filedetails/?id=205801...

As the game development pipelines from traditional engines are much more mature i think the premier way will be to develop there and just export to HTML. Resulting Apps are heavier though, so for small web only games or just some enhancement effects, there is still room for lightweight WebGL engines like three.js

But with Unity you can have one codebase and export to Win/OSX/Linux/iOS/Android/HTML5 and even consoles while some HTML5 engines offer an acceleration wrapper for iOS but thats basically it.

What is the performance like for asm.js and WebGL compared to a native app for PC or Mac? What do you lose?

WebGL is basically at native speed. The only issue might be if a GL extension you need is not in WebGL yet, but that is moving along quickly.

asm.js can run close to native speed, depends on the JS engine of course, but it's not far off. See for example

https://github.com/joelgwebber/bench2d

To qualify, close to native speed means about two thirds of native speed in a best case scenario. Fine for games that don't stress the hardware to its limits, but not for top tier.

First of all performance is CPU+GPU, and the GPU side is basically at native speed. Many games are mostly GPU bound, so for them they would run at full native speed.

For games that are CPU bound, two thirds of speed is the current average on a set of benchmarks on Firefox, yes. But it will vary on codebase, and is constantly improving.

Regardless, you say that top tier games won't work. What is UE4 and the higher-end stuff Unity demoed, if not top tier?

Why does asm.js run so crappily on Safari/Mac?

Because it uses JSC instead of V8.

Yes I wish that would change too. A port I did of something ran well in Chrome and Firefox, but terribly in Safari

I find it annoyingly disingenuous for Mozilla to pride itself on a "plugin-free web" when they are the ones making decisions that ensure languages other than Javascript will NEVER run without plugins.

Please stop hurting all of us with this artificially imposed Javascript monopoly

Yes, let's invent/promote a bunch of select technologies to the extent of directly integrating them into _some_ browsers and then call-it a "plug-in-free web". At least they came up with asm.js...

Article does not address licensing terms; what's in it for Unity?

More sales, I imagine. If Unity can add chrome support then this could a pretty big deal for gaming on the web!

They have already proved (Lego Starwars demo IIRC) that they can target the NaCL runtime for Chrome (and ARM Chromebooks). But I'm not sure when/if they plan to release that publicly.

I think it makes more sense for them to aim towards some sort of unified platform. NaCL is cool and all, but it's very Google specific. WebGL is now even supported in the latest versions of IE.

As a company they surely do not care if something is Google specific or not. They only care if they can sell enough licenses for it to make the development costs make sense. In light of chrome's adoption curve it seems to be a not terrible idea to target nacl.

Or they could just target WebGL and asm.js, which already works in Chrome, and let's see how long Google sits around with Chrome being slower at a popular use case.

Exactly, and it was also driven by the fact that it was easy for the Unity guys to get their existing toolchain building on NaCls LLVM toolchain. Now with ASM.js maturing, its another great opportunity.

Also we saw Unity developed a target for the Flash runtime (now with Flash pretty much dead, thats being shelved). Gotta give props to Unity for trying.

Yeah. Target asm.js and WebGL and you'll get Internet Explorer 11, Chrome, Firefox, IE and probably eventually Safari. With NaCl you get Chrome only. The choice is simple.

The choice wasn't so simple when asm.js was only supported by Firefox, and Microsoft had no plans to support WebGL in IE. :)

asm.js is supported, inherently, by all modern browsers. It is just JavaScript, after all. However, only Firefox has a second compiler path especially for it. Chrome has some optimisations for asm.js-like code in V8.

Well, yes, but I find the WebGL port of the Unreal Engine demo (for example) unplayable without asm.js-specific optimizations. So by "supported" I really mean "optimized".

a subset of a language is not the language itself. asm.js is not javascript.

Wait a sec, are they saying the Unity5 webgl exporter will only work in firefox?

Unity is a tools company. This is just another target platform for them, so they can sell more licenses for their software.

Each platform for Unity has another license associated with it (eg: $1500 for Android Pro, another $1500 for iOS Pro). Another web target would be another $1500 license for folks to buy annually, I imagine.

Maybe they'll give it away in the free version like with Web Player authoring. Well, I can hope :)

When they were doing the Flash version, it wasn't free. Still, one can hope!

That was imposed by adobe not unity.

Unity has an Asset Store as well as a yearly subscription to their software's Pro version. More users = more sales + more conversions to Pro

That seemed like the obvious next step for Unity after they dropped Flash and with browsers increasingly dropping NPAPI plugins; always nice to see predictions come true :)

Wow, i have been waiting for this for years and wondered what took them so long. I love Unity and while its not free, other HTML5 engines will now have a hard time.

i wouldn't say they'll have a hard time - unity is just another choice among the hundreds of engines out there for web.

I would say that it benefits more people who aren't interested in programming. Unity is the visual basics of game programming.

I'm curious to know how networking behaves in a webgl build. Will my tcp sockets just work straight out of the box? That would be seriously impressive!

They won't, but changing your server to accept websocket instead shouldn't be too bad.

Don't even need to do that. There are a bunch of TCP-WebSocket bridges out there.

Even though you can go with websockets or a tcp-websockets bridge, Mozilla has a proposal for TCP Sockets API in JavaScript. Its being used in Firefox OS right now and is quite cool. More info at:

https://developer.mozilla.org/en-US/docs/WebAPI/TCP_Socket

In the future this could become a standard and everyone would benefit.

This is a really good news as I have developed some small games in unity and I wished that I can create it using HTML5. So will there be a tool for creating graphics also or we have to follow same old html and images for that. And will there be an option to port games to android, iOS and blackberry??

I'm curious if the generated JS files will have Source Maps to trace back runtime issues to the C# code.

I wonder if and how C# scripts (a big part of the Unity framework) are supported for the WebGL target.

C# scripts aren't used in the final output.

Unity is an engine where the scripting portion is Mono based, upon export it is converted into C/C++/Obj-C/Java for Desktop/mobile/web platform of choice. It will be similar for javascript, the exported asm.js supported javascript will emit from the export to WebGL.

Unity runs in the native platform it is in but Mono is their 'scripting engine' and part of their core engine much like UScript/UnrealScript is UDK's scripting engine. Unity uses Mono a little deeper than that but the resulting export is optimized for the platform it exports to. Since it is built on .NET it is alot like LLVM/JVM languages in that the IL/CLR/DLR are used to export all common languages used in scripting to a common output and this is also the reason you can use C#/Javascript/Boo (Mono versions) as they export to the same thing in the end native to the platform they are on.

I am sure there will be pluggable areas of the outputted javascript but for the most part you'll develop it as usual in Unity and won't mess with the output as much except to plugin third party toolkits etc.

To clarify a bit here...

Unity didn't say that 100% of Unity features will be supported in WebGL. Some scripts will, most likely, not be able to run in the WebGL builds initially. Also... Things like GI, or the new PhysX... I wouldn't count on if you are wondering how to prepare a game to be WebGL ready.

That said, I'm certain they will improve the WebGL build tech as time goes on, and eventually MOST of what anyone would need will be available. It just won't be available on day 1 of Unity 5.

The exported user scripts are actually .Net assemblies. They are run via the mono VM using it's JIT (just in time) compiler on platforms that support it, and are AOT (ahead of time) compiled on platforms that don't like iOS.

In the case of WebGL the .Net assemblies are processed by a tool to convert them to C++ and then compiled into javascript using emscripten.

you say what you want, I doubt professional, experienced game devs choose to release quality game with unity.

unity is great for young devs, prototyping and content creators, but it's not that much open so I doubt many dev really like to use it.

still a great thing for mozilla though

Yup, little teams like Rovio with there obscure games about pigs trying to steal eggs wouldn't dream of something like that. Or that game no one's heard about where you launch aliens into space. couldn't possibly work in Unity.

coolish indie games, not that much popular either

Yes, it's good enough for games that rely on brand/marketing more then tech. Also good to increase the profit margin, since you don't need to hire developers - scripters should be enough for most cases.

I'm seeing parallels between Unity and Flash (circa 2000). In a few years, we'll have the "Unity is dead, use <insert some other shiny technology> arguments popping up all over HN

Is that a bad thing? If something better comes along then it deserves to displace unity!

Did Flash ever compile to JS+HTML?

I followed this link looking for a live demo. I was sadly disappointed. This is certainly something I need to experience before passing any judgement.

I'm curious if they'll also add features such as In-app Purchases given that's a recurring issue in threads about HTML5 games.

Amazon is one good option for IAPs with web games:

https://developer.amazon.com/public/solutions/platforms/weba...

edit - Forgot to mention, they even have a Unity plugin:

https://developer.amazon.com/public/solutions/platforms/cros...

That is only for Android (Kindle) apps afaik

Interesting option indeed, it even has an AIR version.

I really hope so. They should work with a partner like Steam or Google Checkout to make it easy to do IAPs in the browser.

Are you talking about https://developer.mozilla.org/en-US/docs/Web/API/Navigator.m... ?

Thanks, that's an interesting option as well indeed.

Immediately after a flash video is the quote "... strengthens support for Mozilla’s vision of a high performance, plugin-free Web,"

...

looking forward to a demo. This could be a nice way of getting Unity3d games to platforms unity doesn't support yet (Firefox OS devices, Ubuntu Touch etc) if the performance will be good enough.

Who would be interested in "Unityify", an adaptation of Browserify that supports Unity3D's dialect of JavaScript? It would package npm modules so they ran in Unity, and include some shims to wrap the native Unity3D classes in node APIs.

Too bad it's not WebGL 2.0.

When will Dead Trigger 2 be available for purchase on the web?

So, that's why they've been doing, instead of fixing the 64 bit version and improve multi-threading support.

Let's hope it works as advertised then.

You do realize that exactly the same Unity 5 announcement also announced 64 bit editor and improved multi-threading?

Reply on news.ycombinator.com