Artillery is building a hardcore RTS with HTML5 and WebGL

Fixed set of hardware, that the developers could easily target and build their skills.

For the gamers, just put the cartridge or disc, and start playing.

No need for driver updates, or whatever else might be required.

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

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.

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

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

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.