I know someone who used to make a living writing erotica for the Kindle store and experimented with using inklewriter to create interactive, CYOA-style stories. For a small donation to a charity, the inklewriter devs would compile a story to a static .epub which could then be published on the Kindle store.
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.
There were books using this differently where it would skip to the end to get a paycheck out of it. Thats probably why. Not cause of a CYOA. I think it was posted about here on HN. This is an interesting comment though. I hadnt thought of ever seeing a CYOA book in digital form but I guess it makes total sense.
Here's a prior discussion on another technique that's somewhat related called "stuffing":
Ink and Inkle (the editor) look like a great system. They remind me a bit of Inform 7 (except ink is more markup and Inform 7 is more structured natural language).
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...)
Does Ink have an object-oriented world model like Inform, or is it all about branching narrative based on the user's choices?
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 have not actually used Ink myself. But from looking through the introductory documentation, the world model seems fairly simple and more like the branching narrative type you mention -- and nowhere near as sophisticated as Inform 7 which can essentially do almost anything and parse any phrase. Which makes sense given the very different needs of a CYOA system like Ink (with restricted choices). However, Ink does support some state variables (like whether you visited a location) so it can be somewhat more complex than just a branching narrative. Ink may also have other features that were not obvious to me at first glance though.
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.).
Ink is much closer to a markup language than a full programming language (though it does support variables, branching, loops and functions). Where Inform lets you build an interactive world, special-case certain interactions, and provides a full parser, Ink is geared more toward text-heavy, choice-based IF. It's much more fine-grained than something like ChoiceScript (basis for ChoiceOfGames stories).
This suite of tools looks like a fun way to teach kids programming while boosting their writing/storytelling skills and even a gateway into game programming.
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.