[sillysaurus3]

Has WebGL solved the local storage limitation yet? I've been waiting for a few years for that. There's still no way to "install" a game into a browser, as far as I know, and redownloading 1GB+ of assets every time the game loads isn't an option.

[vertex-four]

If, for whatever reason, you're hell-bent on producing a AAA-quality game with javascript and WebGL, you could always use something along the lines of node-webkit[0] and distribute it the usual way.

Personally, I rather significantly doubt that people would play more AAA games if they could download them in their browser rather than Steam.

[0] https://github.com/rogerwang/node-webkit

[sillysaurus3]

Why wouldn't you want to produce a AAA-quality game with javascript and WebGL? It should be the default, not some crazy thing.

The best argument against javascript + WebGL is "javascript is bad." But the disadvantages of JS are sometimes strengths. The lack of static typing, for example, allows a REPL. It's true that with an average gamedev team, you'll get below average results. But with an above-average team, powerful languages tend to translate into stellar results.

Oh well, I guess I'll wait a few more years for browser vendors to implement some kind of concept of a webapp installation.

[the_af]

> The lack of static typing, for example, allows a REPL

Uh? Languages with static typing can have REPLs. See: Scala, Haskell and more. I don't think that is what makes JS an option for game development, but rather its ubiquity in browsers. If you remove that, I don't see why you would choose it for serious development.

[sillysaurus3]

Why does Haskell have a REPL but not Go?

[judk]

Haskell has an interpreter as well as a compiler. No one cares enough about making one for Go.

I used a C interpreter a decade ago.

[pkroll]

A quick Googling would have shown two REPLs for Go, though they're old and haven't been updated in a long time. I'm guessing the Go playground and "go run file.go" compiling and running so quickly, make it not a real concern.

[the_af]

I don't know why Go doesn't have a REPL, I'm not familiar with the language. My point is that having static typing does not preclude a nice REPL.

[lmm]

Because Go sucks? What point are you trying to get at here?

[sillysaurus3]

My point? Before I get to my point, how about a rant: It mystifies me how nobody sees the obvious advantages of in-browser games, both for development and deployment. It should be obvious to anyone in the field, because the current method of developing and deploying games completely sucks. Do you honestly think that in 100 years, people are going to be deploying games through Steam, or worrying about cross-platform OS support? If so, you may want to rethink that. If not, then why wait 100 years? There's no reason to put up with the current limitations.

Except, oh wait, the only reason we do have to put up with the current limitations is because we're beholden to the browser manufacturers to implement support into their browsers for features that gamedevs will use. Like, say, having a >5MB area to store art assets. I'm pretty sure that's the only real reason we're not seeing in-browser games. Not because JS sucks. Not because WebGL sucks. But because even if you actually do make a game using a browser as the platform, there's nowhere to store the damn thing!

So, back to that "point" you were asking about. What was my point with my oh-so-pointed "Why does Haskell have a REPL but Go doesn't" question? Well, it was a question. The thing you ask when you want to learn something. In this case, I had no idea why Go (a statically typed language) doesn't have a REPL, when Haskell (a statically typed language) apparently does. In fact, I had no idea Haskell had a REPL at all! I had no idea that it was even possible for a statically typed language to have a REPL. Those ideas seem as separate as oil and vinegar. So it's pretty damn cool to hear that it is in fact possible and practical to have a REPL for statically typed languages, and now there's a mystery: Since REPLs are such a productivity boon, why don't all statically typed languages have them? I'm not at all afraid to admit ignorance; I wear it on my sleeve. It's the only way to learn. But I guess we're so far gone, here, that people misunderstand a simple question meant to learn something as some kind of snide, rhetorical, or coy remark.

So, yes, sure. Go sucks. JS sucks. WebGL sucks. Steam is amazing. The only real way to develop a game is with C++, deployed as a native OS binary, or with someone else's engine, also deployed as a native OS binary. Keep the status quo. Pretty boring, isn't it?

[dragonwriter]

> Why does Haskell have a REPL but not Go?

Because no one's bothered to create a REPL for Go.

[shard972]

> Why wouldn't you want to produce a AAA-quality game with javascript and WebGL? It should be the default, not some crazy thing.

Performance. Show me some like gears of war running in a browser and then I will be convinced.

> The best argument against javascript + WebGL is "javascript is bad."

That is the worse attempt to portray the other side's argument I have seen a while.

> The lack of static typing, for example, allows a REPL.

You can also just have a console implemented, like most AAA games. They are also built into engines like Source.

> It's true that with an average gamedev team, you'll get below average results. But with an above-average team, powerful languages tend to translate into stellar results.

I don't understand how javascript would allow someone like John Carmack to make anything new, I write Javascript every day but when it comes to games I much prefer something like c#.

[sillysaurus3]

Look up Unreal engine in the browser. It runs quite nicely.

You're right that I did a poor job explaining why people are against JS for gamedev. Sorry about that.

[squeaky-clean]

The only game demo I can currently find for UE4 in the browser is Flappy Chicken (I know they had some up earlier, but they seem to be taken down). Not really a compelling AAA demo. And their 3D games still only run about half as fast as a native C++ engine. That's very impressive, but you won't be putting out AAA games with a 50% performance hit.

And even then, unreal engine in the browser doesn't run Javascript written by developers. It compiles the C++ code into asm.js. Huge difference. Unless you can code asm.js by hand, you won't be able to do that. Here's a sample of the Flappy Chicken UE4Game-HTML5-Shipping.js file, because the code is just too long and ugly to paste.[0] Definitely not 'JS for gamedev.'

[0] http://i.imgur.com/O3w61XI.png

[sillysaurus3]

This has been up for three hours, and it's telling that no one has replied to it with a rebuttal.

[easong]

You could always package the game as a node-webkit app.

[nbody]

AppCache?

[sillysaurus3]

It sounds like AppCache limit is 5MB. I can't find very much info, though, but a reasonable limit for gamedev circa 2014 would be 16GB or so.

http://grinninggecko.com/2011/02/24/developing-cross-platfor...

http://stackoverflow.com/questions/6757945/cache-manifest-si...

[mschuster91]

There are the HTML5 local filesystem extensions, in addition to that. Just no idea how these are called.