For one, C++ and the native toolchain is still more efficient. But it mostly comes down to perception and convenience. The perception of web-based games is that they're casual and cheap. And most hardcore gamers like to have a copy of the game on their computer - they paid for it, they want a copy that they can keep (and at least store on their hard drive) for years. They don't want to stop playing a game because the dev decided to end its life...

This is why platforms like Steam, Xbox, HumbleBundle, etc..., still rule for distributing games (both AAA and indie).

My personal concern with the browser is more about the freedom of game developers to tweak the app as they want. You're very vulnerable in a browser in term of how you can use the keyboards and how the client will receive what you're trying to show them. For instance, in starcraft2, you use "ctrl+1" to bind an army to the key "1". In chrome, ctrl+1 switches to the first tab. Some webapp uses hacks to go around that.. for instance, with Asana, you use the [tab] key, such as [tab]C to go to the comment section.

Everyone talks about performance issues.. but if the trend continue, it won't be a problem. But I'd agree that right now it's still hard performance-wise.

Maybe one way to solve these problems is to have a gamer browser. Could be based on V8 and even have the look&feel of Chrome, but small parts would be tweaked to make it gaming friendly. Maybe no plugin allowed, more resources dedicated to it, performance optimized for certain tasks, etc.

There's a low barrier to entry to trying something that runs in a browser. I just navigate to the page, wait for a progress bar, and maybe bookmark the game if I like it. The low barrier to entry is one reason that flash games are still so popular. http://xkcd.com/484/

Even assuming this IS what console are for, why in the world are you going to complain about more competition in the market for a good way to distribute games?

But that's irrelevant. What matters more is if they will catch-up to being "good enough", and that is likely to happen.

I personally think WebGL IS good enough to make quality games, I have no issue with it. I just don't think it will catch-on with the gaming public for other reasons. Look at how much resistance there was to Microsoft's 'always-on' feature of Xbox One, to the resistance to DRM that calls home (it is annoying if you're trying to play a game somewhere that you have no connection), and then the requirement that the developer also maintain infrastructure.

The current system, where you create something native using a cross-platform toolkit, then distribute it once, and the user has it forever - this is what gamers are used to, and what they like. And I admit, it's nice being able to play games when I have no internet connection. I don't think this paradigm is necessarily the best one, but it certainly has its merits.

I'd be more concerned about how easy it would be to reverse engineer a web game compared to a native binary. If it's easy to bot or cheat, any competitive aspect will be ruined.

Kinda neat to be honest. Doesn't stop me yelling at map hackers tho ;)

If you look at this HTML5/WebGL minecraft engine, it stutters even without any other players or bots in the environment.

http://voxeljs.com/#gallery

Meanwhile Minecraft running in Java is smooth on even the slowest machines.

Benchmarks indicate that Javascript is 4x slower than Java.

http://j15r.com/blog/2013/07/05/Box2d_Addendum

The alternatives like ASM.js and PNACL are far from usable. ASM.js has no support for threads and PNACL is unlikely to be supported outside of Chrome. They also have no debugging support.

The choice of Java in your argument is kind of ironic to me.

Also 10 years ago Java was nowhere near as fast as it is now. If you are saying that Javascript might be an option 10 years from now, I am not disagreeing with you.

My minecraft server can get bogged down just my wife and I playing. That's on a core2duo 2.0GHz with 4GB.

It plays better on my phone.

After your experience with both native and WebGL game development, don't you think it's a little premature to make a hardcore game targeting only WebGL?

Thanks for sharing Irrlicht engine with us!

When emscripten is passed the debug flag, it will generate source maps, which will let you step through your code, although inspecting variables still isn't a solved problem.

Meanwhile, back to the ladder. Grandmaster can't be too far off... ;)

Pathfinding is Hard. Maintaining sync is Hard. Unit AI is Hard. And keeping those performant is doubly so, especially using JS.

So yeah, I'll be impressed if they get anything playable out of this.

https://www.google.com/search?q=rts+pathfinding

Lots of people asking for solutions, lots of different solutions, lots of caveats.

For starters, yes there are complex problems with lots of edge cases indeed. But not one of the many problems you suggest are computationally difficult. Now there are some computationally difficult problems to deal with in an RTS but those are not among them.

Additionally, a large amount of the problems you just listed are common among any game with AI. RTS pathfinding is hard, but so is pathfinding an an FPS, and then add in how much more complicated a level is in a game such as Assassin's Creed, to the more simplified structures you can manage in an RTS, and it's easy to see why this isn't simply a matter of RTS games being simply more difficult.

And within an RTS there very many problems that are much easier, both from a complexity, and computationally then in other games. Visibility determination is one thing in particular that's considered super difficult, and very performance sensitive, that's very easy to solve with the fixed perspective of an RTS.

And then there is networking, in which case you can use a lock-step model in RTS due to being less sensitive to latency, that both vastly simplifies networking. And also makes it possible to synchronize the large amount of units in an RTS with minimal bandwidth.

I'm excited that you guys are pushing browser gaming, and what you've done so far looks great. Just please don't fall into the trap of over hyping and then disappointing customers.

Respect for putting that on your company page. It's good to see core values like these!

There are 2 main advantages of web over native games. The first is being able to quickly jump in and play with a friend. The second is being cross platform including all mobile devices.

These 2 reasons are why I'm building my multiplayer tower defense game http://www.towerstorm.com in javascript. I'd be interested in trying out your engine if you're looking to make it run fast on mobile along with PC.

How's your experience with your game? Is it really slow or does it run fine? I'm asking regarding all platforms.

However it has taken some time to optimize the code to run fast enough on all these devices. The main issues I've come across are normal game algorithm issues (using a quadtree to find nearby minions, using hashmaps instead of arrays for some data that is always searched by id etc) and garbage collection. Garbage collection has been an annoying issue which I've somewhat solved by using entity pools. So instead of creating new entities and deleting them when they die a pool of entities is created at the beginning. Then upon creation each entity is pulled from that pool and after it dies all its variables is reset back to zero and it is placed back in the pool to be used again later. This uses up a lot more memory but it means the game doesn't have a large CPU spike every few seconds as it does garbage collection.

Canvas performance may be an issue once I turn it into an iPhone app as I've heard the canvas app renderer has far worse performance than the browser renderer (I have no idea why), but I'll cross that bridge when I get to it.

So in summary I think it's fine for simple casual 2D games that don't have complex logic (using A* algorithms to move large groups of units may be too much, or having advanced AI). But anything designed to appeal to hardcore gamers who need 60+ FPS and want in depth gameplay may be a bit much for it for now.

A common feature required for RTS games is being able to just push your cursor to the edge of the screen to move your viewport. (Since it's played full-screen.) It seems like a browser game would be missing this key feature.

:-) Developed at Seneca College in Toronto, Canada.

new favorite platform, and hopefully new favorite RTS.

I'll just remain appreciating what these developers have been able to do from a distance until I can learn the basics myself. Programming these games is only half the work, it's the art direction, storyline and mechanics that make up the other 50% of the work to make a game in any language or framework.

The first produces html5 and abstracts a lot of the complexity of the low level that other approaches are based on. The second is more c++ oriented at this point. Hope it helps, or at least leads you to finding your own path to doing it. It also allows you to escape some of the js madness that happens when you interact with this stuff for browser output. It allowed me to get to a level of production that I could not imagine possible just by looking at the opengl stuff.

I think Artillery.com would be a natural partner for our WebGL-based 3D content creation platform. They should check it out at http://clara.io Similar to how Unity3D is a natural partner to the desktop 3D content creations tools like Max/Maya.

Our engine and Project Atlas are written entirely in CoffeeScript, but that's not a requirement of game code.

[disclaimer: I'm originally from Europe, so this is self-criticism]

These posts on HTML5 stuff that pop-up on HN from time to time hint on what is to come on the web in the near term. I think HTML5 is a huge Tsunami gathering energy and steam out there! It will and should beat all these "I-am-the-best" closed systems (already does in some areas) sometime soon, and be on the top.

System agnostic, immersive, inclusive, what not. Love it.

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?

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.

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?

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

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

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.

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.

In the end of the day it's just a script running on top of Open GL.

I, too, like to strip naked outdoors in a Chicago winter and then complain about how the city isn't keeping its streets reasonably well-heated.

So I will use [x] to find a game in [y] and then [z] it to play.

Where: x = {Chrome|Firefox|Steam}, y = {some-sort-of-web-app-store|Steam store}, z = {cache|install}.

I guess the success will depend on how easy and rich x-y-z experiences are, but you will still have to register, pay and download.

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.

They are, but I very much doubt these guys are using the DOM or CSS. And if they're using asm.js then they're using a very different JavaScript, too.

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

* The ability to play the game on other peoples computers

* Cross-platform accessibility (Windows, OSX, Linux? Doesn't matter.)

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

So can Steam.

* Cross-platform accessibility (Windows, OSX, Linux? Doesn't matter.)

10-20% of the games on Steam have Linux ports, and most of the others run fine under Wine.

So 2/3 are better on Steam and the 3rd is primarily a benefit for the developer.

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.

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.

ps - how can we start an hn sc2 group

Not a really good rationale when it comes to game development.

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.

Native will always fundamentally beat non-native, that's a plain fact.

In quality, perhaps. In sales, profit and market share, I'm not so sure.

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.

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.

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.

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.

I believe so, yes.

Assuming there will be 9 billion web users sometime into the future, non-native will be enough for most of the stuff though.

Let me explain. You want to program for the web? Javascript. You want to do 3D? we have you covered, you can only use webgl. Don't like it? Sorry but we need to remain open! want audio? We have an API for that, why would you want to use something else? use Audio API, it's open.

can you imagine if linux, or microsoft windows or OS X only understood one programming language? Or if DirectX were the only 3D thing you can use? or if to use audio, you had no choice but to use one library?

The web is just that, and no, being available on all the platforms does not make it an open platform. It's one big closed transparent prison available everywhere. Once you go in, you are stuck with the onboard equipment.

This is actually a scary prospect, considering how consistent JS is as a language, let alone as a bytecode replacement.

I expect that to happen sooner rather than later, it is not an impossible problem, and it is far preferable to trying to use JS as a compile target.

I seriously doubt that the world will stagnate at HTML and JS. Thing will evolve!

Though judging by adoption and advancements from W3C, it might be thousands of years ;).

Yay! Let's cheerlead the democritisation (read: degeneration) of computer programming! The "open", democratic people got everything wrong, which is why the browser has such a laughable hodge podge of features. Hooray for people who took web programming instead of OS design at college. WOOO!

I think you meant democratisation, or was there some subtle reference to a [famous greek philosopher](http://en.wikipedia.org/wiki/Demokritos)?