Is it possible to somehow use twine 2 as a backend?

Question

For example running it under a node.js or in any other way? So that it is server-based and can be accessible through REST API or smth.

Answer 1

As the project code currently stands: No

If your goal is to store (only) your own Story Projects on a web-server instead of: in your web-browser's Local Storage; or on your own hard-drive (or equivalent); then you could fork the project's repository and then write code to replace the web-browser Local Storage based Story Project persistence module with code that uses REST to save the same data remotely, in a similar way to how the code for the NW.js based release replaces the same section of code with it's StoryFile persistence module.

If your goal is to either: allow multiple Authors to store their Story Projects on a single web-server; or to allow multiple Authors to work on the same Story Projects on a single web-server; then the task becomes a lot more complex because you will need to (at least) implement:

a. Some form of Author authentication (and possible authorisation) system.
b. A method to uniquely ID each Story Project so that there can be no overlap.
c. Functionality the allows the web-server to notify an Author that others have modified the Story Project, and knows how to update the local copy of the project in such a way that neither the remote nor the local changes are lost.
d. The ability for an Author to externally backup their Story Projects.
e. Licencing that protects the Author's rights to their content.

Comments

I was thinking of using it as a logical backed for any other frontend. Let's say, a unity3d client that can send a command/decision and receive a new data to represent, so that story progress is on the server (assuming I have authentication and DB). Currently it is all based on DOM as I understand. I'm wondering if it is possible to trigger html response with xml or something for the next screen as a response to html request with decision.

---

If I understand correctly your third-party client needs access to the run-time version of the story project data, and not the edit-time version of the story project data.

eg. A story project that has been marked in some way that the editing process has finished ('published') and its data is now available for the third-party client to consume.

The first IF statement in my previous comment covers this use-case.

A simpler way to do this is to push the latest/current copy of the project HTML(-like) file created by the StoryFile module of the install-able release of the Twine 2 application to a server, which the third-party client can access. If you like you could convert the contents of that HTML(-like) file into JSON or JSONP either before or after the push.

---

Yes, you are correct it is about run-time version of the story project data. But I thing something else is missing in your suggestion. Yes, HTML(-like) file with the content can be pushed to the server. But it contains only data, while I'd be happy to reuse game engine as well on the server side, not the client side.

What I'm missing from your description, is how to modify the game engine to:

• listen to the event from outside (like when HTML request was received) instead of links clicked events
• repond to this event by sending out a new pack of data instead of editing DOM (which does not exist since the engine on the headless server) so that client can render these option 

---

 is how to modify the game engine to...

As I understand things the main issue with what you're asking for is that at their core the current story format engines are designed to convert the contents of a Passage into DOM elements with attached (Javascript based) behaviour, and based on your second point you don't want that functionality. Nor do you want the other main thing a story format does which is to manipulate core web-browser features like state storage, media displaying/playing and such.

So the real question then is what functionality of the existing story formats do you actually want?
(and I would guess the answer to that question would boil down to be: not a lot!)