There are around 650 Twine projects on IFDB (yup, I counted) and over 6,000 projects tagged with “twine” on Itch.io. While my ongoing research on historical Twine works has not produced a definitive answer yet, my assumption is most of the Itch numbers come from projects created with Twine 2 (after February 2015) while the IFDB Archive has predominantly older works with most created before Twine 2.0 (with the oldest known public Twine work I’m aware of from July 2009).

When it comes to reading post-Twine 2.0 works, there is good documentation on the HTML elements used to store data and how to understand it. (Disclaimer: I wrote it.) For earlier Twine works, those created with Twine 1.3.5 (the first version I used in 2012) or Twine 1.4 (published in December 2013), the last version before the 2.0 shift, the documentation has been lacking. As with many thing open source, until there is strong interest, and one or more people willing to do the labor, certain things will never be done.

One of my many projects in the second half of 2023 has been to fix this issue through writing documentation on every input and output format consumed or produced by any version of Twine. This work began with Twee 3 a few years ago and, more recently, has extended into getting approval of the Twine 1 HTML documentation and, yesterday, submitting the first draft of documentation on Twine 1 TWS (Archive) files. (I also submitted a draft of the Twine 2 HTML Archive format, too.)

Why is this an issue?

From an archival perspective, there are two central problems slowly converging on Twine:

• (A) Browsers update on a regular basis and web languages change over time. While most current web browsers can read and process older JavaScript code, certain uses of CSS and older tricks no longer work the same way. Projects created in 2013 are obviously not designed for mobile devices made a decade later in 2023; some of the oldest Twine works cannot be used on certain devices or in smaller resolutions.
  
• (B) While many older works exist as published HTML, some only exist as TWS files. This means attempting to perform static analysis (reading code as text) becomes harder without clear documentation on how to read, process, and understand its data. Some guesses can be performed based on how HTML works, but TWS files are binary files based on the “pickle” serialization used in the programming language Python, which does not have a formal specification.

Much of my more recent historical research into older Twine works has encountered the second problem in various ways. As the discussion on GitHub revealed, there were some quirks of Twine 1 HTML I was not aware of when trying to document it based on examples I was pulling from the IFDB Archive. At the same time, as I learned today, the TWS format was never documented for Twine 1, which makes trying to reverse-engineer its design 14 years later — Twee/Twine 1 celebrates its 15th anniversary in 2024! — rather frustrating.

As I do more research and work with other Twine developers to refine these documentation files, something becoming quite clear is how much of early Twine development and interactive works created between 2009 to 2015 are poorly studied. The often-cited first major Twine presence in academic circles occurred in August 2014, which was after the introduction of Twine 1.4 in December 2013. Hopefully, as I slowly move forward with my own work, I can begin to fill in some gaps and help others come behind me and use this new documentation to study Twine in the future.