Writing web-based interactive fiction with Ink
inklestudios.com
inklestudios.com
He discovered that the compilation process essentially generated every possible page of text. For example, he would allow the reader to choose the color of the protagonist's hair (blonde, brunette, redhead) and then refer to a $hairColor variable throughout the text. Every page that used that variable would have to be generated three times, one for each possible value. This resulted in a text that was many hundreds or thousands of pages long, even for quite a short story.
At the time, Kindle used a very simple payment model based on the number of pages read. When a reader selected a path, they would jump forward hundreds of pages at a time, each one counting as a read page, and by the end Kindle tracked them as having read thousands of pages. Using this system, he went from earning 2 or 3 dollars for a cover-to-cover reading to literally hundreds of dollars per reading. Of course, they caught on to this and modified the payment policy as well as the thoroughness of moderation and the gravy train ended.
Here's a prior discussion on another technique that's somewhat related called "stuffing":
https://news.ycombinator.com/item?id=17315249
I swear there was some weird one where you opened a book, and skipped to the end and it counted as reading 300 pages.
Another discussion:
StoryHarp is an Interactive Fiction tool I wrote 20 years ago in Delphi and ported to JavaScript in early 2018: https://storyharp.com/
The JavaScript version can generate stand-alone HTML files.
ink is text-based like Inform 7. StoryHarp is more graphically-oriented -- somewhat more like Twine (but different). http://twinery.org/
While Ink is probably more flexible than StoryHarp in its conditionals, there seems to be some overlap in the underlying concepts (as with much IF tools) in providing a list of choices that depend on a current context and some previous state changes. I'd expect it would be straightforward to convert a StoryHarp story to ink. The other way might not work so well though depending on what features of ink were used. Not sure if people would find value in roughing out a story in StoryHarp and then converting it to ink given ink seems fairly easy to use? I guess the question is how complicated things get (where StoryHarp's Smalltalk-inspired tools like a browser, map, and table hopefully start to shine when stories get complex...)
When I commented on this aspect of Twine versus parser-based IF yesterday, I think I showed my bias toward parser-based IF. But thinking about it more, I've concluded that a world model isn't definitively an advantage. I imagine there are many interactive stories that people want to write where the defining features of parser-based IF, locations with objects that are usually used to solve puzzles, would just be a distraction. Maybe the writer wants to focus more on choices and their consequences than on puzzle-solving in a simulated world.
So I don't ask about Ink in order to critize it; I just want to know.
I agree with you that a simpler approach can help someone focus on the story -- which was part of a conscious choice to limit StoryHarp's possibilities via only support simple rules. Although another aspect of that limitation was to make the GUI easier to write and to use -- especially by not having to support editing arbitrary logical statements and not supporting state values that could be other than booleans. While the StoryHarp map is most obviously used to map out locations (or "contexts"), the framework is flexible enough so that these contexts could be any sort of general states like, say, moods (angry, sad, happy, etc.) or general situations (desiring a pet, talking with pet shop owner, inspecting parrot, talking with pet shop owner again, etc.).