I'm starting to feel like no-javascript-guy is some type of HN novelty account. Seriously man, not a single person here cares that you don't use javascript. Move on.
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.
EDIT: Remember, your votes decide the type of discussion you'd like to be having in the future. So down vote me if you'd like to see more bullying on HN.
I care slightly, because it's such a very strange stance to have. I just can't understand this aversion to js. Do they want the browser to just display html forever? Go back to the way things were? Do they actually think that will happen? When the browser is _the_ application platform, what will they do?
I strongly disagree. Gnosis is being ridiculous here in complaining that something interactive needs code, but it's equally ridiculous for non-interactive pages to need javascript. I've seen pages with the entire content in the html, set to invisible, that needed javascript to turn the text black. That is shameful web development. It shouldn't take 10 billion clock cycles to make the page appear. Html, css, javascript, they each have their own jobs, and it's valid to complain when someone does it wrong.
But again, it's only valid to complain about/mock javascript on non-interactive pages like blogs.
> But again, it's only valid to complain about/mock javascript on non-interactive pages like blogs.
Which is a bit part of the point of this, it is an interactive page. Though again I'll disagree further and say it isn't valid at all to simply complain and mock. A reasonable discussion on usage of javascript, or browser-based applications would be worth having. Just saying "not gonna use it" isn't interesting.
Again, you're talking about javascript on application pages. I am perfectly fine with javascript on application pages. My only complaint is when there is no fallback on simple document pages.
"Gnosis is being ridiculous here in complaining that something interactive needs code"
You know, not everything that needs code needs to be run in a web browser.
Is it really so ridiculous of me to oppose opening my browser up to Javascript exploits and spying by the likes of GoogleAPI?
I'd be happy to run the game in any of the 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.
Standalone engines are subject to fewer attacks from untrusted code, so they're probably easier to exploit than a browser. So I can't really agree with you on a security perspective. And incognito mode / using a separate browser profile / portable browser installs are all options to completely preserve privacy that are either as convenient or more convenient than installing an interactive fiction engine.
"Standalone engines are subject to fewer attacks from untrusted code, so they're probably easier to exploit than a browser."
Probably? This is purely speculative.
I'd be interested to see any actual exploits of Interactive Fiction engines. So far, they are a much less attractive target to malware authors than web browsers are. That alone makes me prefer them over web browsers, no matter what their theoretical vulnerabilities may be.
"incognito mode / using a separate browser profile / portable browser installs are all options to completely preserve privacy"
Users are often tracked by their IP addresses as well as OS and browser fingerprinting, which Javascript can facilitate. Try going to Panopticlick[1] with Javascript turned off and then with it turned on and see the difference.
"that are either as convenient or more convenient than installing an interactive fiction engine."
But I already have multiple Interactive Fiction engines installed, so using them is perfectly convenient for me. As for others, how many people do you think actually bother to use a separate browser profile or even "incognito mode"? Not a hell of a lot. And if they do, they might also do what I do and disable Javascript altogether.
>So far, they are a much less attractive target to malware authors than web browsers are. That alone makes me prefer them over web browsers, no matter what their theoretical vulnerabilities may be.
I sympathise but find it quite contrary that you prefer to download standalone engines over something sandboxed in the browser. Although I believe there is some unknown percentage of users who won't turn on Javascript for this game, I can only imagine that a vanishingly small percentage of those might take a stance similar to yours.
The other obvious flip-side of your argument is: Javascript has a much bigger potential audience than IF engines these days. That alone makes Javascript preferable to develop for. The security and privacy issues do not make enough of a dent in Javascript's userbase to make this a serious consideration for developers.
I never claimed that developers or the vast majority of users are going to suddenly abandon Javascript once they heard my oh-so-compelling argument against it.
In fact, I don't expect them to.
Most users are ignorant, technologically illiterate, blind to security issues, and lacking of any concern for their online privacy. Most developers aren't much better, and aim for the low-hanging fruit, without many scruples as far as respecting the privacy of their users goes.
No. Most of them aren't going to change. But that doesn't mean that I'm going to suddenly give in and start using Javascript myself. And though I be a lone voice crying in the wilderness, I'm going to stand up for what I know is right.
"he is instead annoyed by your post to announce your minor decision to the world"
Well, I'm annoyed by these other people's announcements of their minor decisions to play this game despite it being a threat to their security and privacy.
So, I don't agree with the mouthbreathing masses. It won't be the first nor the last time.
You know these same people would probably be exploited by some dancing baby app, punch the monkey game, or porn app which they fell all over themselves to install, and then announced to the world how great it is!
Yeah, I don't want to be hacked or tracked like the rest of these morons are. Sue me.
I'm sorry, what basis do you have for saying 'your browser has been owned,' as if it were inevitable and I were merely unaware of it? Just because I have JS enabled does not mean I'm indifferent to security. Besides my OS, I also monitor traffic through my router and modem.
Please don't assume that your abundance of caution entitles you to dismiss others as ignorant or indifferent to security matters.
All I'm saying is that absence of evidence is not evidence of absence.
It's possible that your security has been compromised and you are simply unaware of it. It's great that you monitor your network and take other security precautions. It would probably be even better if you also avoided running Javascript apps written by people you don't trust. Wouldn't you agree?
I use noscript, and am continually annoyed by web pages that feel they need to run code on my computer to load. I get it when people complain about things needlessly using Javascript.
With that in mind, what the hell were you expecting? Even in the 90's web based games used flash. What exactly was the 'secure' alternative? A game needs to run code, whether natively or in your browser.
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.
'Secure' interpreter? Fair enough. I'm afraid that would likely make it harder to get started though. Not to mention that JS probably has support for better graphics assets than a regular text game interpreter.
"JS probably has support for better graphics assets than a regular text game interpreter."
This game was billed as a "minimalist text-based game", for which any of the standard Interactive Fiction interpreters would have been more than adequate.
Incidentally, many of these IF interpreters are able to display graphics, and sometimes even sound -- though the usefulness or appropriateness of those features in the context of IF is debatable.
This is not an interactive fiction game. While primarily text-based, it uses rich UIs based around that text, and the input mechanism is not command-based, but instead generally button-based (or in the case of the third and fourth parts of the game, partially arrow-key-based). In addition, the end of the game isn't actually text-based at all.
The developer would have to ship their own custom engine, at which point you have unsandboxed code running under your user account on your computer, instead of code sandboxed in the browser (which is probably the most generally available and secure sandbox for arbitrary code that exists right now). You are quite unlikely to give the game a full code review to make sure it's not making any analytics requests or shipping your data off to the program author, so that is probably worse from a logical security standpoint.
Now, if you're worried about the request to load JQuery from ajax.googleapis.com, you could've pointed out originally that this is a concern for those who worry about their privacy, and most on here would agree with you. I'm not actually sure why the author of this game decided to use the CDNed JQuery, when the rest of their scripts are unoptimized and loaded from their own server.
> If the source is available to the public it is open source.
That's not the usual definition. The usual definition of "open source" revolves around having an open source license.
> I may not have a copyleft license, but for that we have other terms like "Free Software".
"Free Software" and "open source" are approximately equivalent (the FSF "free software" definition and the OSi standards for "open source" aren't identical, and there are probably some license that meet one but not the other, but they are close enough in practice that its not a huge difference.
"Copyleft" is a much narrower term than either "open source" or "free software". Most open source or free software licenses are not copyleft.
The style of a minimalist interface that starts sprouting things, somewhat ASCII-game-ish yet also rather dynamic, reminds me a bit of Candy Box: http://candies.aniwey.net/ . It's an interesting UI and 'reveal' style for a game, and glad to see another one using it. Feels somewhat refreshing.
edit: Ah ok, if you view-source it mentions Candy Box as an inspiration.
Seems to use the psychological technique of intermittent rewards to encourage continued clicking of "stoke the fire." Unfortunately after about 4 stokings with no new developments in the game, I got bored and quit.
In this and candy box you're not really supposed to pay attention to the window for the first couple minutes. There is literally nothing to do.
Then later once you're maybe 10 minutes in you can switch away for extended times if you want to wait for the continuous income, no need to press buttons, no 'intermittent rewards'.
It could be changed but it's not actually depending on any kind of psychological tricks. The delays are just a minor throttle at the start.
Edit: Actually, to be precise, you only have to stoke the fire once. It's just a deliberately paced cutscene. No psychology there.
> In this and candy box you're not really supposed to pay attention to the window for the first couple minutes. There is literally nothing to do.
Yeah, interesting call, that. When I played Candybox, I was told "before you dismiss So what it, wait until you get 60 candies, then shit gets real".
So, what does a self-respecting hacker do, when faced with 60 seconds of "literally nothing to do" ... except the challenge of opening the JS Console to see if I can make that counter run faster, preferably in less than 60 seconds? ;-)
After two times stoking the fire the room changes from cold to mild. There is also a shivering stranger stumbling into the room. Of course you can still be bored by that, but it is not true, that there is no new development.
Another tip for fighting: equip different weapons. I had only equipped the best weapon, as is customary in games, not knowing you can attack with all equipped weapons at once basically (each weapon has a separate timer). This makes a huge difference.
I ran this in console. just to automate gathering wood and trap checking, since forgetting to switch between panels is easy to do:
function pushButtons(){if(!$("#gatherButton,#trapsButton").hasClass('disabled')){$("#gatherButton,#trapsButton").trigger('click');}}setInterval(pushButtons, 1000);
I just realized what this really does. It just sets up a second callback to Engine.collectIncome. So when you go to set it "back", you end up with 3 income collecting loops. If you try to set it "back" multiple times you end up with more income loops.
Darn, guess I'll have to start all over again on my PC.
Seems like there'd be a use for a way to "save" games by emailing a parameterized URL to yourself... Or just an alternative to arrow keys for all of those tablet users out there.
Still a great game, though! Next time I'm feeling like procrastinating on a 2007 vintage netbook, I'll know where to look :)
I think it's actually using local storage, which is a bit harder to get at. But I ended up surpassing my iPad game within 15 minutes anyway... Good fun :)
This is probably a simple question, but I'm new to JavaScript: How did you create the side-scrolling animation effect that happens when you switch between locations?
I really like the source code for this game! It's quite readable and good fun to look over :-) Now I remember this was my original reason why I was interested in programming - wanted to figure out these mysterious listings for test-based adventures on Atari. I really like how all the possibilities are encoded there, but you can't entirely picture the game until you actually play it :-)
Anyone figured out how to explore the "landmarks" on the dusty path. Like I see the caves but I can't enter them, move my guy over them but no matter what key I press he won't enter.
This is pretty damned cool, and it looks like there is a lot of thought out content backing it....I thought I'd look at it and move on, but I've been playing it for awhile
Anyone figured out how to explore the "landmarks" on the dusty path. Like I see the caves but I can't enter them, move my guy over them but no matter what key I press he won't enter.
I played this to completion a week ago. It can feel a little tedious st times, but this is usually because I missed something, and is ultimately well written at all stages. Keep with it and you won't be disappointed!
Warning: while the first part of the game works fine in a touch-based interface, a later section requires a keyboard. You'll be annoyingly unable to proceed on a touchscreen.
244 comments
[ 3.5 ms ] story [ 258 ms ] threadI 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 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.)
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.
[1] - http://frotz.sourceforge.net/
[2] - http://www.logicalshift.co.uk/unix/zoom/
[3] - http://inform7.com/
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.
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]:
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.
[1] - https://news.ycombinator.com/item?id=5961281
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.
No thank you to opening my browser up to Javascript exploits and GoogleAPI tracking!
EDIT: Remember, your votes decide the type of discussion you'd like to be having in the future. So down vote me if you'd like to see more bullying on HN.
Obviously, you didn't live through the age of X11 popup adds or javascript exploits.
But again, it's only valid to complain about/mock javascript on non-interactive pages like blogs.
Which is a bit part of the point of this, it is an interactive page. Though again I'll disagree further and say it isn't valid at all to simply complain and mock. A reasonable discussion on usage of javascript, or browser-based applications would be worth having. Just saying "not gonna use it" isn't interesting.
You know, not everything that needs code needs to be run in a web browser.
Is it really so ridiculous of me to oppose opening my browser up to Javascript exploits and spying by the likes of GoogleAPI?
I'd be happy to run the game in any of the 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.
[1] - http://frotz.sourceforge.net/
[2] - http://www.logicalshift.co.uk/unix/zoom/
[3] - http://inform7.com/
Probably? This is purely speculative.
I'd be interested to see any actual exploits of Interactive Fiction engines. So far, they are a much less attractive target to malware authors than web browsers are. That alone makes me prefer them over web browsers, no matter what their theoretical vulnerabilities may be.
"incognito mode / using a separate browser profile / portable browser installs are all options to completely preserve privacy"
Users are often tracked by their IP addresses as well as OS and browser fingerprinting, which Javascript can facilitate. Try going to Panopticlick[1] with Javascript turned off and then with it turned on and see the difference.
"that are either as convenient or more convenient than installing an interactive fiction engine."
But I already have multiple Interactive Fiction engines installed, so using them is perfectly convenient for me. As for others, how many people do you think actually bother to use a separate browser profile or even "incognito mode"? Not a hell of a lot. And if they do, they might also do what I do and disable Javascript altogether.
[1] - https://panopticlick.eff.org
I sympathise but find it quite contrary that you prefer to download standalone engines over something sandboxed in the browser. Although I believe there is some unknown percentage of users who won't turn on Javascript for this game, I can only imagine that a vanishingly small percentage of those might take a stance similar to yours.
The other obvious flip-side of your argument is: Javascript has a much bigger potential audience than IF engines these days. That alone makes Javascript preferable to develop for. The security and privacy issues do not make enough of a dent in Javascript's userbase to make this a serious consideration for developers.
In fact, I don't expect them to.
Most users are ignorant, technologically illiterate, blind to security issues, and lacking of any concern for their online privacy. Most developers aren't much better, and aim for the low-hanging fruit, without many scruples as far as respecting the privacy of their users goes.
No. Most of them aren't going to change. But that doesn't mean that I'm going to suddenly give in and start using Javascript myself. And though I be a lone voice crying in the wilderness, I'm going to stand up for what I know is right.
More to the point, if at least you didn't care, then why did you comment?
Why didn't you "just move on"?
Well, I'm annoyed by these other people's announcements of their minor decisions to play this game despite it being a threat to their security and privacy.
So, I don't agree with the mouthbreathing masses. It won't be the first nor the last time.
You know these same people would probably be exploited by some dancing baby app, punch the monkey game, or porn app which they fell all over themselves to install, and then announced to the world how great it is!
Yeah, I don't want to be hacked or tracked like the rest of these morons are. Sue me.
You mean you have yet to become aware that your browser has been owned through some Javascript exploit.
Somehow that isn't very comforting to me.
Please don't assume that your abundance of caution entitles you to dismiss others as ignorant or indifferent to security matters.
It's possible that your security has been compromised and you are simply unaware of it. It's great that you monitor your network and take other security precautions. It would probably be even better if you also avoided running Javascript apps written by people you don't trust. Wouldn't you agree?
With that in mind, what the hell were you expecting? Even in the 90's web based games used flash. What exactly was the 'secure' alternative? A game needs to run code, whether natively or in your browser.
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.
[1] - http://frotz.sourceforge.net/
[2] - http://www.logicalshift.co.uk/unix/zoom/
[3] - http://inform7.com/
This game was billed as a "minimalist text-based game", for which any of the standard Interactive Fiction interpreters would have been more than adequate.
Incidentally, many of these IF interpreters are able to display graphics, and sometimes even sound -- though the usefulness or appropriateness of those features in the context of IF is debatable.
The developer would have to ship their own custom engine, at which point you have unsandboxed code running under your user account on your computer, instead of code sandboxed in the browser (which is probably the most generally available and secure sandbox for arbitrary code that exists right now). You are quite unlikely to give the game a full code review to make sure it's not making any analytics requests or shipping your data off to the program author, so that is probably worse from a logical security standpoint.
Now, if you're worried about the request to load JQuery from ajax.googleapis.com, you could've pointed out originally that this is a concern for those who worry about their privacy, and most on here would agree with you. I'm not actually sure why the author of this game decided to use the CDNed JQuery, when the rest of their scripts are unoptimized and loaded from their own server.
You prefer running a binary to play a game?
If you trust native code simply because it's open source, why don't you trust browser-interpreted code?
That's not the usual definition. The usual definition of "open source" revolves around having an open source license.
> I may not have a copyleft license, but for that we have other terms like "Free Software".
"Free Software" and "open source" are approximately equivalent (the FSF "free software" definition and the OSi standards for "open source" aren't identical, and there are probably some license that meet one but not the other, but they are close enough in practice that its not a huge difference.
"Copyleft" is a much narrower term than either "open source" or "free software". Most open source or free software licenses are not copyleft.
edit: Ah ok, if you view-source it mentions Candy Box as an inspiration.
- Wait until you have 60 candies (new options appear)
- Click the cowboy hat 4 times
- Buy the wooden sword
It is just worth mentioning from time to time.
Frog Fractions is much more linear, I suppose. You move from one game type to the next, instead of having multiple in parallel.
Then later once you're maybe 10 minutes in you can switch away for extended times if you want to wait for the continuous income, no need to press buttons, no 'intermittent rewards'.
It could be changed but it's not actually depending on any kind of psychological tricks. The delays are just a minor throttle at the start.
Edit: Actually, to be precise, you only have to stoke the fire once. It's just a deliberately paced cutscene. No psychology there.
Yeah, interesting call, that. When I played Candybox, I was told "before you dismiss So what it, wait until you get 60 candies, then shit gets real".
So, what does a self-respecting hacker do, when faced with 60 seconds of "literally nothing to do" ... except the challenge of opening the JS Console to see if I can make that counter run faster, preferably in less than 60 seconds? ;-)
(answer: yes, it was in fact fairly easy)
http://www.indiana.edu/~p1013447/dictionary/sked.htm
Edit: I got bored quickly anyway, probably because I just don't find computer games to be a satisfying way to spend time. Never have.
window.Engine._incomeTimeout = setTimeout(Engine.collectIncome, 500) // default 1000
IMO it's not a cheat, because it just shortens somewhat tedious waiting early in the game, but doesn't alter it otherwise.
Another tip for fighting: equip different weapons. I had only equipped the best weapon, as is customary in games, not knowing you can attack with all equipped weapons at once basically (each weapon has a separate timer). This makes a huge difference.
function pushButtons(){if(!$("#gatherButton,#trapsButton").hasClass('disabled')){$("#gatherButton,#trapsButton").trigger('click');}}setInterval(pushButtons, 1000);
See inside and outside at the same time
var stoke = function(){if(!$('#stokeButton').hasClass('disabled')){$('#stokeButton').trigger('click')}}
var check = function(){if(!$("#trapsButton").hasClass('disabled')){$("#trapsButton").trigger('click')}}
var gather = function(){if(!$("#gatherButton").hasClass('disabled')){$("#gatherButton").trigger('click')}}
g = setInterval(gather, 1000) c = setInterval(check, 1000) s = setInterval(stoke, 60000)
This works:
function pushGather(){if(!$("#gatherButton").hasClass('disabled')){$("#gatherButton").trigger('click');}}setInterval(pushGather, 1000);
function pushCheck(){if(!$("#trapsButton").hasClass('disabled')){$("#trapsButton").trigger('click');}}setInterval(pushCheck, 1000);
function pushStoke(){if(!$("#stokeButton").hasClass('disabled')){$("#stokeButton").trigger('click');}}setInterval(pushStoke, 60000);
Seems like there'd be a use for a way to "save" games by emailing a parameterized URL to yourself... Or just an alternative to arrow keys for all of those tablet users out there.
Still a great game, though! Next time I'm feeling like procrastinating on a 2007 vintage netbook, I'll know where to look :)
Love the minimalist interface.
Even though it was surprisingly mostly playable on mobile (except: small buttons, tooltips)