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.
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.
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).
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.
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.
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.
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.
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.
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
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.
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.
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.
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?
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.
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
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'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!
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??
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.
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.
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
[+] [-] mrspeaker|12 years ago|reply
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!
[+] [-] kayoone|12 years ago|reply
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.
[+] [-] null_ptr|12 years ago|reply
[+] [-] SimHacker|12 years ago|reply
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.
[+] [-] GavinB|12 years ago|reply
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.
[+] [-] endemic|12 years ago|reply
[+] [-] neovive|12 years ago|reply
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.
[+] [-] papa_bear|12 years ago|reply
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).
[+] [-] kayoone|12 years ago|reply
[+] [-] NinjaWarrior|12 years ago|reply
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.
[+] [-] WiseWeasel|12 years ago|reply
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.
[+] [-] Joeri|12 years ago|reply
[+] [-] ANTSANTS|12 years ago|reply
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.
[+] [-] valarauca1|12 years ago|reply
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.
[+] [-] wildpeaks|12 years ago|reply
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.
[+] [-] Touche|12 years ago|reply
[+] [-] davexunit|12 years ago|reply
[+] [-] azakai|12 years ago|reply
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.
[+] [-] kayoone|12 years ago|reply
[+] [-] VikingCoder|12 years ago|reply
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. (???)
[+] [-] jiggy2011|12 years ago|reply
[+] [-] lotsofmangos|12 years ago|reply
Bananabread? https://developer.mozilla.org/en/demos/detail/bananabread
[+] [-] matt_heimer|12 years ago|reply
[+] [-] darklajid|12 years ago|reply
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.
[+] [-] beefydude|12 years ago|reply
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.
[+] [-] gcp|12 years ago|reply
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.
[+] [-] azakai|12 years ago|reply
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.
[+] [-] rossmckegney|12 years ago|reply
[+] [-] zenbowman|12 years ago|reply
Pre-Unity, game engines were truly stuck in the dark ages.
[+] [-] drawkbox|12 years ago|reply
[+] [-] basicallydan|12 years ago|reply
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...
[+] [-] kayoone|12 years ago|reply
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.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] coldcode|12 years ago|reply
[+] [-] azakai|12 years ago|reply
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
[+] [-] pekk|12 years ago|reply
Please stop hurting all of us with this artificially imposed Javascript monopoly
[+] [-] tomcam|12 years ago|reply
[+] [-] wildpeaks|12 years ago|reply
[+] [-] kayoone|12 years ago|reply
[+] [-] chii|12 years ago|reply
I would say that it benefits more people who aren't interested in programming. Unity is the visual basics of game programming.
[+] [-] Cakez0r|12 years ago|reply
[+] [-] tarun29061990|12 years ago|reply
[+] [-] wildpeaks|12 years ago|reply
[+] [-] mixedbit|12 years ago|reply
[+] [-] drawkbox|12 years ago|reply
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.
[+] [-] jokoon|12 years ago|reply
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
[+] [-] jon-wood|12 years ago|reply
[+] [-] thetannedman|12 years ago|reply
[+] [-] jiggy2011|12 years ago|reply
[+] [-] danabramov|12 years ago|reply