We may be seeing the same HTML5 demos on HN, but we're living in two different universes. In my world, I always open up these demos in a browser that's incompatible. If I do manage to get them working, my reaction is always like wow, I saw better native demos 10 years ago, and those just worked.
Let's be honest. JavaScript, DOM, and CSS are terrible technologies to base any gaming system off of. As a gamer, performance is critical and stuttering ubiquitous in HTML5 games is unacceptable.
For a gamer who disables mouse acceleration, had a CRT until low latency gaming LCDs were available, and tracks his Star Craft APM, what does HTML 5 buy me other than performance issues?
It's easy to talk trash on a technology that is in its infancy. Wait... WebGL games are still not as good as game engines that have been developed for 20 years? SHOCKER.
The technology is only going to get better. The whole point of these demo's is to show what is possible even now when the specs aren't finalized and the technology is barely adopted. Give it 3-5 years and I would be willing to bet you'll need to eat your words.
> Wait... WebGL games are still not as good as game engines that have been developed for 20 years? SHOCKER.
That's the point, isn't it? We already have all these fast, battle-tested game engines Heck, we have 15-year-old game engines that run on the browser (or do Flash games no longer count?). Is it really worth it to toss all that out and switch to WebGL?
Is it worth replacing a proprietary plugin (which the owner may stop supporting at any time) with an open standard (which has guaranteed continued development)? Yes, I believe it is.
Used to think that when I was high on WebGL in summer 2011. Sure some progress was made since then but really not as much as I expected. I really thought "by 2013 this will run on ALL browsers and on MOST mobile devices out-of-box, no config flags needed". We're still not there yet by a long shot.
So you're saying it'll be another 3-5 years? That's cool by me, I'll check back in 3-5 years then. This stuff is easy enough to pick up for anyone who has a grasp on basic modern OpenGL workings anyway..
I think there are two different points which kind of render the comparison difficult to make:
- html5 games are defacto multiplatforms, since tbey must support all the popular browsers, and underlying systems (mobiles, tablets, PCs...). Compare this with the Wintel supremacy of early RTS days,
- This is technology preview material, available to a potentially very large audience. I don't think RTS did get such exposure during their development, especially during the eary days, when people wanted to disclose as little as possible to the listening competition in the gaming news channels (nainly magazines).
There are some absolutely amazing HTML5 / WebGL things out there; I'm just not sure you've seen them. It's true that browser incompatibility is an issue, but say you're ONLY targeting Chrome desktops, which still has a bigger user base than most consoles--if you're doing it right you're getting hardware accelerated graphics and the performance is pretty great. Have you seen cloudparty.com? It has multiplayer in-world building, skeletal animation, particles, full screen effects... the works, and the performance is definitely up to snuff. Observe tons of realtime screencasts here: http://www.youtube.com/user/CloudPartyInc
I think that the problem is that WebGL is young and there are LOTS of ways to shoot yourself in the foot perf-wise. Only a few teams have really figured it out and the rest are making the tech look bad. But the performance is there if you're an experience graphics programmer and you know your way around JS wackiness.
After going through a few of those examples, the performance really isn't that good. For example, in Chrome my computer struggles to run "The Isle of Yosemite" in 1650x1050 at 30fps when looking at a fair bit of geometry. Yet I can easily play Battlefield 3 or Natural Selection 2 at 30fps, and the gulf in image quality, how much is in a given scene, and how much game logic there is is enormous.
Thus far, HTML5 games seem more like a replacement for basic 3D flash games more than anything. Whether that will change at some point in the future I don't know, but at this point I have not really been wowed by anything.
I've come across browser games a number of times that wouldn't work in my regular browser, requiring me to switch to another one I have installed. Your analogy is not very apt.
Also unlike Steam you might have to re-download the whole thing if your browser decides to clear the cache for whatever reason. Can't play underground, on a plane or while camping as well (not a typical scenario though - nitpicking a bit).
There's work going on for better app caching systems at the browser level. This is a UI and platform issue, but there's no tricky technical aspects. The user expresses the intent of wanting to cache a web app, and it is cached locally.
But crucially you will be able to buy on the app using x,y,z, and continue to play the app using a,b,c from different hardware/software vendors, unlike the situation today with say a game bought on a mac.
That's the advantage of the web over native APIs, and why I think its ethos will eventually win out - it is better for developers and users, but not for the corporations who would like to sit between the two as intermediaries.
Not when deployed with something like node-webkit which I would assume would be a common deployment strategy so you can guarantee Chrome and a certain version w/ certain features enabled/disabled.
Granted, it's a terrible abuse of a CSS, but it's also a perfect example of how I'm supposed to be wowed by a buggy HTML5 demo my PC could render better in every way 15 years ago.
And no one has answered my question yet. What benefit does HTML5 bring me as a gamer? Why are HTML5 games better than native games in my steam library, especially considering DSL is my only option for Internet here?
* The ability to play the game without installing anything
Obviously you haven't played any HTML5 games. They all make you wait to download game data. And if the Internet gods have been good to you, it won't be cleared from your localstorage next time you start it up. Steam is far better.
* The ability to play the game on other peoples computers
Apples and Oranges are being compared here. The difference between Steam and web games is like the difference between video files and Youtube. Youtube is always of inferior quality, but it can play almost anywhere anytime. You don't need a windows machine with administrative rights.
HTML5 may not bring any benefit to you as a gamer, but it has the potential to bring the games to millions of other people who don't use Steam.
I don't see HTML5 being used for creating cutting edge games. I do see it being used to create smaller, less graphically intense games that easily hook users.
>> What benefit does HTML5 bring me as a gamer? Why are HTML5 games better than native games in my steam library, especially considering DSL is my only option for Internet here?
more people making games and more people playing them. i don't think anyone thinks the browser is the end all be all platform to deliver a game. just like some games run on OS X and some don't, and some games are on Steam and some are not. some games will be in the browser and some won't.
i hear you on the technical concerns. lots of problems. but the vendors recognize this and have a vested interested in fixing it.
> I saw better native demos 10 years ago, and those just worked.
Agreed. But you're missing the point. In those 10 years those of us who played in the native universe will not be the target market any more. Just like we listeners of Pink Floyd and Metallica aren't the target buyers of Justin Biebers and Lady Gagas of the day. The latter are as successful, immersive and relevant to those who matter.
> JavaScript, DOM, and CSS are terrible technologies to base any gaming system off of.
Now this is an opinion based on the current_level_of_performance (which I agree is not at the expected level.). But it's not a great way to judge what the future could hold. It's definitely a bet, like you said let's be honest with this.
>Now this is an opinion based on the current_level_of_performance (which I agree is not at the expected level.). But it's not a great way to judge what the future could hold.
Native will always fundamentally beat non-native, that's a plain fact.
Native will always fundamentally beat non-native, that's a plain fact.
Consider the barriers to browser performance:
Hardware acceleration - already there with WebGL and for video codecs
The JS language - this can be swapped out for something more performant - various options exist but it will take time and a brave vendor to do so.
Rendering speed of HTML etc - this can be improved, both by simplifying things like the box model and by improving the renderer, we've already made huge strides int this area for standard UIs.
These are solvable problems - eventually web properties could easily be compiled (in a sandboxed language or VM), and become native. I don't think there's necessarily a difference between a sandboxed process in a browser VM, and a sandboxed process on the desktop. Just because browsers are still developing and in the past have not been performant in comparison to native APIs, doesn't mean things always have to be that way. So while the present performance comparison of native to HTML means native wins (as long as you don't just do everything in webgl say), things don't have to stay that way.
The greatest strength of the web platform is that it is simple, open, and extensible. This also makes it a bit of a mess of competing standards and leads to a problem with legacy cruft (like the reliance on JS), but it has held up remarkably well, and has proven flexible, simple and incredibly popular. It's difficult to charge people money for content on the web, but not impossible and that's more to do with culture than technical challenges. It's also difficult to lock people in on the web - that's something people hate about native which isn't going away.
Eventually I expect the internet, and the web in particular, will reduce operating systems to a badly debugged set of device drivers (Andreessen was prophetic in that regard), and operating systems will be replaced as a concept and become simply the interface to hardware, which implements some standard APIs for the web and acts as a container for the VM which runs the code. We're not far from that situation already, and it is preferable for consumers and creators/developers. The only thing standing in its way are the vendors of large ecosystems (hardware and software) like Google, Apple, MS and Amazon, who have a vested interest in corralling and controlling their customers and keeping them inside an area where they set the rules and can take a cut on every transaction.
I'd argue the resurgence of native mobile platforms is the last hurrah of native, and simply another attempt to lock people into an ecosystem controlled by one company, it will fail as people start to realise their loyalty to say Apple is not rewarded. We'll probably see these companies grudgingly adopt the web, while still trying to corral their customers (it's what companies do when they get to a certain scale), but on the web that is much harder to do, because it's an open API, controlled by no-one.
Most things running on the desktop aren't sandboxed. Whether they should be or not is a different matter.
Hardware acceleration will by necessity be limited when one is required to sandbox, as in a web browser. It's the difference between accessing an array item by "arr[i]" and accessing an array item by "if i>arr.len || i < 0: crash, else arr[i]". Some checks can be compiled out, but some cannot. And there will always be cases where a human can identify that something cannot happen but a compiler cannot prove it. Look at the number of cases in the Linux kernel where there's assembly macros, for example.
As for the web being a "simple, open, and extensible" platform, I'd argue otherwise. Simple? Have you looked at the amount of mostly-duplicated css required to just do a simple cross-browser gradient? Open? Good luck using anything besides HTML/javascript/CSS. Even Java is blocked by default now. Extensible? Only if by extensible you mean "you can have any language you want, as long as it's javascript."
I agree that native locked-down mobile platforms are the worst of all worlds. That being said, I don't see why non-locked-down native platforms are bad.
There are good points, though I would say they're not insurmountable in most cases. I think desktop is moving towards sandboxed too, and will inevitably become more restrictive following Apple's lead. I think that's a good thing and we have the resources now to get that increased security without losing much performance.
Simple - I do think the simplicity of the web is is its greatest strength - it does limit what you can do with the web, but it also means it is not too hard to either produce content or create a browser (though nowadays the browser part is pretty challenging). CSS gradients are a good example in fact of the messy web process of experimentation, consensus, and eventual convergence - you will soon be able to use the prefixless style and not worry about several prefixed versions. Personally I'm not sure prefixes are a good idea anyway, but they do go away eventually.
Open - I meant as in anyone can contribute to the standard, and any vendor can write a browser, no one party controls it, as they do native platforms. I'm quite happy Java is blocked given who controls Java :) On the server of course, you can use whatever you want, whatever framework, language and paradigm you like, which is quite liberating when compared to say creating apps for iOS.
Extensible - well the standard actually allows for other languages, and JS being the only scripting language is more a quirk of history than anything else - there have been moves to allow byte code instead (Nacl), and I suspect that's the way things are heading - to a sandboxed VM which will run any compiled language. When that happens then a huge range of languages will open up, just like server side.
That being said, I don't see why non-locked-down native platforms are bad.
The biggest reason they're bad from my point of view is that they don't cater as the web does to hardware not invented yet (as the web does), obsolete hardware, or to other hardware platforms and are locked-in to a particular chip and instruction set, even if not locked down to an API. The other disadvantage is that you are locked in to whatever API (and typically language) the platform has chosen - everything must be written with that language, or with glue code interfacing to that language.
That's the big difference with the web - it defines a limited reference platform (the browser) which can be made for any hardware, and anyone can target using any server side tech they want. There is a clear division between client and server, and both can change completely without invalidating the other. That's a very powerful abstraction and one which I think gives it an advantage as a platform against any native platform which rivals it.
> Native will always fundamentally beat non-native, that's a plain fact.
The problem of WebGL is simply it has very low penetration. By my research, currently only 35% of desktop users can use WebGL with GPU acceleration (FYI, Flash 10: 95%, Flash 11: 75%; Flash 11(Stage3D with GPU): 70%). Now that IE11 is supporting WebGL, this might be a matter of time. However I foresee it would take 5 years or so to achieve 80%.
And, note that WebGL only has functions of OpenGL ES 2.0. Currently WebGL2, which has functions of OpenGL ES 3.0 is being developed. On the other hand, native games already utilize OpenGL 4.x. What API is used in native games when WebGL2 becomes popular? I imagine raster-based rendering might be obsolete at that time.
And I think people already know the web can't handle Oculus Rift, probably one of the most interesting, innovative and fun gadget in this decade. Of course you can use it on browsers with a NPAPI plugin. Oh, hey, the web people said plugin is obsolete and evil! Don't use plugins!!! Don't play with Oculus Rift, you, PLEASE!!!
I admit the web platform has some value on some points, but if people think HTML5 is the (only or most) cutting-edge and innovative technology, that's not correct. Absolutely not.
* if people think HTML5 is the (only or most) cutting-edge and innovative technology, that's not correct. Absolutely not.*
I don't think anyone could argue that - the web is a messy consensus, and definitely doesn't include cutting edge, innovative tech (except perhaps server-side if you want). That's not its strong point but I think the other points in its favour do make up for it.
Re WebGL, I suspect if we see killer app(s) come out using it, penetration will spread quickly and it will be kept up to date by browser makers. At present it's a bit of a chicken and egg situation.
Let's be honest. JavaScript, DOM, and CSS are terrible technologies to base any gaming system off of. As a gamer, performance is critical and stuttering ubiquitous in HTML5 games is unacceptable.
For a gamer who disables mouse acceleration, had a CRT until low latency gaming LCDs were available, and tracks his Star Craft APM, what does HTML 5 buy me other than performance issues?