6 ms·

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

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 https://github.com/rogerwang/node-webkit

sillysaurus3 12y ago
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.
- shard972 12y ago
  > 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 12y ago
    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 12y ago
      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 http://i.imgur.com/O3w61XI.png
- the_af 12y ago
  > 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 12y ago
    Why does Haskell have a REPL but not Go?
    - judk 12y ago
      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.
    - lmm 12y ago
      Because Go sucks? What point are you trying to get at here?
      - sillysaurus3 12y ago
        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?
- sillysaurus3 12y ago
  This has been up for three hours, and it's telling that no one has replied to it with a rebuttal.

sillysaurus3 12y ago

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.

shard972 12y ago
> 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 12y ago
  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 12y ago
    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 http://i.imgur.com/O3w61XI.png
the_af 12y ago
> 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 12y ago
  Why does Haskell have a REPL but not Go?
  - judk 12y ago
    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.
  - lmm 12y ago
    Because Go sucks? What point are you trying to get at here?
    - sillysaurus3 12y ago
      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?
sillysaurus3 12y ago
This has been up for three hours, and it's telling that no one has replied to it with a rebuttal.