Using Twine to make a path through an OpenSim build

I haven't been blogging as regularly as I ought. I have, however, been reading blogs and a couple of articles caught my eye this past week.

First Robin Heyden has some excellent tips for running virtual training sessions. One important point she makes is the need to train students only for the task at hand to avoid overwhelming them with detail.

The second article was by Cathy Moore who describes use of the TiddlyWiki-based Twine to generate e-learning scenarios. Twine itself is a visual editor for interactive fiction stories with passages (aka as tiddlers/chunks) linked to show pathways through the story (see lefthand side of picture above for really crude example).

Underpinning Twine is a specialist language called twee that provides useful macros to manage the reader experience. I looked at twee in the very early days of this blog with the intention of using a third-party information manager called Treeline to generate twee code for processing into standalone TiddlyWikis. However, being purpose-designed, Twine helps a lot in implementing paths through a scenario, visualizing them and outputting versions in special TiddlyWiki formats (Jonah or SugarCane) or as plain twee-formatted text for proof-reading. See Cathy's blog for a better explanation together with the videos by Twine's creator, Chris Klimas.

Putting these two ideas together, I wondered about the possibility of using the client web browser to display a story or backstory to a class, including branches for optional just-in-time help in the client browser. Bear in mind that not all of the following has been developed or tested.

The Twine and twee documentation give the background though some of it, text-formatting for example, is standard TiddlyWiki markup. As with any TiddlyWiki, you can include embed images and html in the document using the appropriate tags.

More interesting, however, is the notion that you could use OpenSim http-in functions to provide links from the backstory to inworld and thereby deliver objects, notecards, etc as avatars click links in the backstory. The problem here though is that the relevant function, llGiveInventory, requires the avatar's key while Twine by default appears to have no macro to set user-specified variables such as the avatar's name or key.

The simplest way round this for my small class (20 maximum) would be to give students a list of numbers as backstory links so that choosing one takes the student to a page that sets the twee variable $avatar_id to a string between 1 and 20 (the maximum number in my first semester class) and a link that returns them to the main pathway. (I've only included two options as branches in the lefthand side of the image above). I'm using a string in this instance because I want to concatenate it to other strings to generate twee code that will represent the URL.

When students login, they touch a prim that allocates a unique number in the aforementioned range while at the same time recording their name and key against that number and opening the backstory in the in-client browser using llLoadURL. You might use OSSL to store this data in a notecard. The connection between the browser is made when they follow the number-specific branch I described above.

Subsequently any backstory URLs that generate http-in links are generated on-the-fly. For example, the code shown on the righthandside window in the picture would create a hyperlink that tells the receiving prim inworld to give a notecard to the avatar who clicked the link. Of course, that requires some complementary inworld scripting in LSL. The prim might just as easily give a landmark for a teleport step, an object for them to rez or, indeed, temp-rez an object automatically.

This strategy doesn't as things stand prevent one student from pretending to be another but I'm trusting the them not to play games with the system!

One of the avatars on NWG has written a much more sophisticated inworld quest system but it depends in part on an external database. Here the "database" resides in the TiddlyWiki JavaScript and I am hopeful that the same system should be usable from sim-on-a-stick without internet connection. We shall see.

Of course, there are downsides, notably coping with sim and viewer issues (crashes, restarts) and communicating back from the sim (not crucial unless you are making the TiddlyWiki the focus or attempting to create VLE/LMS-type functionality). Reloading the TiddlyWiki in the event of accidentally closing it may also be an issue. Bugs in twee macros are also problematic, not least with the continued evolution of TiddlyWiki and web browsers generally and the fact that Twine/twee and the version of TiddlyWiki used are no longer under development.

How would you use it? Clearly you could be very prosaic and just employ it to step students through some inworld activities (as per the example above). Alternatively, you could develop some more or less fanciful role-play scenario ("there's an outbreak of a previously unknown disease -- go at once to the virtual situation room" or "you are gene id xyz: what is your sequence, what's nearby on the genome, what do you interact with and how is your activity regulated?"). You could also have different stories for the same space and have students compose stories to explain a space and then try each others out.

If you read Cathy Moore's blog, she suggests interspersing text scenarios with activities rather than integrating the two as here. Clearly, that's an option as well. As the TiddlyWiki will run fine in the browser on my Android tablet, you also potentially have a means of generating content that can be read out-of-class without access to the sim. As Twine can import and export twee code, you can also author from a simple text editor.

Linden Lab are becoming increasingly interested in using Second Life for games so it would not surprise me if we see more of this kind of activity. For me it is yet another way to integrate the complementary strengths of text and 3D immersive environments.