Many people know Twine as a good tool for creating quick narrative games in HTML. With its story map view showing the connection between different sections it makes for a great first-time tool for people making games. Yet, what is often forgotten when thinking about passages, the internal units of Twine, as sections of a story is that they are also an internal form of storage.
Twine works by embedding its code and content into the same HTML document. When run by a browser, the code is read and transforms its elements into a story. As the player progresses through the story, the content of different passages are shown through reading from the elements in the HTML document.
This little detail about how Twine runs is important to remember because story formats like SugarCube, one of the three built-in story formats with the current version of Twine, come with functionality to retrieve the text content of passages while it is running. As HTML elements themselves, this passages content can be retrieved and even changed. And this makes them the perfect place to place data for a story within the story itself.
Through getting the contents of a passage, splitting it into an array, and then accessing its entries, it is possible to get a random entry to drive procedural generation systems. Combining these simple steps with more complex rules, picking and combining things, for example, could drive even more complex integrations where one database of entries is picked at random and used as a seed for other operations and choices.