So much so, that I had to write an extension for Chapbook to have variables set when you click a link, because Chapbook assumes that (mostly) you will be writing that sort of “links alone” sort of game, but people don’t want to do that even in Chapbook. 
7 Likes
Another reason an IF Author who has chosen to use Twine for their project quickly descend into the land of JavaScript and macro language usage is that those answering their “how do I” questions will more often that not:
- first recommend using SugarCube as the Story Format, because it is seen as being less “limiting” in the long run, because it allows the direct usage of JavaScript to extend a project’s functionallity.
- supply answers that include JavaScript in them, even if it’s only the usage of JavaScript data-types like Array and Generic Objects. They will often include other HTML5 related technologies like CSS for styling and HTML elements for content structure.
So like others have said before me, it is technically possible to build a Twine project without any coding other than Markup based Links, but evidence where individuals ask questions shows few are doing that.
3 Likes
In my experience it doesn’t seem so much like the people answering questions are pushing complexity on Twine newbies, but rather that a lot of Twine newbies come in nursing grand plans that would require that complexity. Like, I don’t see people coming into a Twine help space going “I would like to make a straightforward branching Time Cave style CYOA” and being told “You should do it in SugarCube and make sure you learn about arrays and object properties before you start!”, they’re coming in going “How do I make an RPG? How do I make a dating sim with a ‘true ending’ that you can’t reach until you’ve gotten all the other endings? How do I make a management sim with an elaborate system for buying and selling items?” and people suggest using SugarCube or provide solutions that incorporate JS because either the things the newbie wants to do are impossible to do otherwise or alternate “lower-code” methods are likely to be convoluted and not work as well.
10 Likes
@EJoyce I’ve found, in my limited time helping Twine authors, that most of my JS/CSS based solutions come from the live interactive side of things, like drag-and-drop or trying to add a CSS style that needs a container <div> to achieve the desired effect. So I agree with you. It’s usually the things that aren’t inherent to a simple train of logic.
@Greyelf I see where your coming from too. I was ripping a hole in Harlowe awhile back trying to expose it’s underbelly. I think it’s because a programmer will look at a problem with the tools they have, not the tools the person asking for help has. If you ask your knowledgeable neighbour (who has a lot of experience with construction) to help you dig a hole, they’re going to bring a backhoe, not a shovel. They may even say, it’s easier to remove a section of fence to bring the backhoe in, and just put up the fence again. 
So when a novice asks an expert for help… I see where you’re coming from.
Anyway, I just chimed in because I don’t think either of you were contradicting each other; and both had valid points.
The biggest culprit is the browser. It’s the best and worst thing for IF because if the browser can handle it, why can’t Twine do it? And then the rabbit hole is uncovered and you want to help the person (who’s stuck in there), but you gotta climb down the hole with them… so you bring your gear.
1 Like
As a symptom of this, I think the most common response to people asking questions about how to do something in Harlowe is “you should switch to sugarcube”, and the motivation for that is usually that (a) the answerer knows more about JS than Harlowe, and (b) the desire for more power! in their toolset, even if it’s not needed, and just bewilders the questioner.
I see that very often. “Can I do X?”, “Well, the browser can do X, so of course!” and never mind the complexity it might involve.
3 Likes