The point is that it's valuable for game developers to realize that some people can't play a game that requires javascript. The comment helped facilitate that.
Everyone can plan a game that requires javascript. A vanishingly small number of people actually wont. Reading anything more into this single comment is silly.
From your comments you seem to actually be interested, so let me tell you about it from my neo-luddite POV.
I love games ( I actually _pay_ for games I like ). I also run with my browser fairly locked down. If you've made a game like this and want me to take more than 10 seconds on the web page, at the bare minimum have it load _something_ without scripts and without requesting anything from another domain ( this means jquery, google apis etc )
This game is a great example of one I wouldn't look at because it loads nothing until a request to googleapis is enabled and scripting is turned on. Perhaps it is overly judgemental on my part, but I assume that failing to provide _any_ level of graceful degradation in a design indicates a poor effort. It takes 5 minutes to add this to your landing page and will save you a tiny percentage of bounces.
tldr: make sure your landing page loads something. anything. Ideally a short message telling users what awesome things enabling the site scripting does for us.
I don't know if that's necessary here. How is someone supposed to get to this page without knowing it's a game? And if someone that turned off javascript doesn't expect that a game might need code, well, I'll have more fun laughing as the door hits them on the way out than I would having 0.1% more traffic.
(I would agree with you if there is some significant flow of visitors that don't already know it's a game, but not until then.)
"And if someone that turned off javascript doesn't expect that a game might need code, well, I'll have more fun laughing as the door hits them on the way out"
Have you ever heard of games that don't run within web browsers?
That's what I thought this particular game might be.
In fact, there is a slew of standalone, non-browser-based Interactive Fiction game engines like Frotz[1], Zoom[2], and Inform7[3] out there that this particular game might have been written in. And I would have had no problem playing it then.
It is a web based game and uses Javascript, there isn't anything specifically wrong with that. Why is it objectively superior to have distributable binaries that have to be compiled or ported for each architecture and OS? What is the fundamental advantage here?
Honestly, aside from not making a point in your initial comment you chose to make it in an unnecessarily snarky manner. Completely uninteresting and irrelevant to someone saying "hey check out my game". If you don't want to check it out, then don't, it isn't necessary to share that non-information with the rest of us.
I'm sure most of us (as I can see from the extended comments on this here) would have been more than happy to have a reasonable discussion on the pros and cons of browser based distribution of applications if you had started there instead of where you did.
"It is a web based game and uses Javascript, there isn't anything specifically wrong with that. Why is it objectively superior to have distributable binaries that have to be compiled or ported for each architecture and OS? What is the fundamental advantage here?"
First, I much prefer open-source games, where I can see the code. So I would avoid binaries. And whether an app I use needs to be recompiled for some operating system other than the one I use is really not my problem.
Second, I loathe the move to making everything accessible only through the web, usually through bloated, insecure web browsers and crappy web technologies. If 99.9% of the web died tomorrow, I would be overjoyed. This includes virtually everything done in Javascript (not to mention Flash).
Third, I've yet to hear of an exploit of a standalone Interactive Fiction engine, while Javascript browser exploits are a dime a dozen. I prefer not to make my browser more vulnerable by running untrusted, unnecessary Javascript code.
Fourth, I don't want to be tracked through spyware like GoogleAPI, thank you very much!
"Honestly, aside from not making a point in your initial comment you chose to make it in an unnecessarily snarky manner. Completely uninteresting and irrelevant to someone saying "hey check out my game"."
Except that developers did find it interesting. Like the following comment from sillysaurus[1]:
As a game developer, I care. Any sign that my potential audience is
cut by a technology choice I make is valuable information to me.
And my comment clearly generated a lot of discussion, so I feel I made a positive contribution.
"If you don't want to check it out, then don't, it isn't necessary to share that non-information with the rest of us. I'm sure most of us (as I can see from the extended comments on this here) would have been more than happy to have a reasonable discussion on the pros and cons of browser based distribution of applications if you had started there instead of where you did."
I should have gone in to more detail as to why I am opposed to running Javascript in my browser, and why I prefer to run standalone apps rather than web-browser apps. And had I seen the gigantic backlash that my little comment generated, I would have -- had I not gone to sleep immediately after making my comment. So I'm replying now that I'm awake. I hope my current comment helps clear up why I made my initial (all too brief and snarky) comment.
> Why is it objectively superior to have distributable binaries that have to be compiled or ported for each architecture and OS? What is the fundamental advantage here?
Speed of execution, and independence regarding what you can do with a browser, compared to what C/C++ offers you, especially libraries and access to the metal.
I'm not saying those are better ways to make games, but if you want real time stuff, like physics or animating several units at the same time, real time inputs, networking, a browser is not going to cut it. A browser is not an OS in itself, it just makes apps easier to make.
The web has been developing a lot since v8, it's really a good thing for developers who want to make things quickly, with pretty good performance, but I doubt it enables dev to do all sorts of applications imaginable. Games are mostly always resource intensive.
This game is really great, but remember, it's free, doesn't seem to run well on smartphone (when in fact v8 aimed to do just that), and it's not like it will be the most played game in your life. You can't make people buy this or play it at a game show. This game is a pearl, it's well done and I had a very good time with it (although short, and I doubt I'll come play it again), but it does not mean all game should be made using this platform.
"That's what I thought this particular game might be."
Well, you were wrong. This is a great game BTW. I'm hooked. Turn on JS and enjoy, or go play with what allow yourself.
Game developers should learn that Amish people exist, at which point they're aware that all computer-related things will have people who choose to not them. They'll also learn that it's not a big deal.