Wood shedding and debugging

Inventing is all about tooling and re-tooling your ideas, staying flexible so that rabbit holes don't distract you from what you want to make, right? On that note, Wikispaces, the platform that hosts my class wiki, is not working at the moment. So, if you go to it and get an error message, please keep trying. I was trying to archive my "Who did it in the Woods? Twine html file there so you can download it to try it out. I found accessing files from Github requires re-saving from .txt to html format, and doing so, I found some strange behavior in the browser, so before I direct folks there, I want to figure out how to make the .txt files converted back to html work.

So ... I've finally arrived at a "Who did it in the Woods?" draft, after 11 versions, that I like enough to release for feedback. Once the class wiki is back up and running, I'll add it and let you guys know. It was a great experience to understand the balance between crafting a well told story and backing it up with scripting, which can be a tricky balance. Tips from what I found worked best for me:

First off, I'd recommend tackling the technical scripting in your story-line, THEN back-filling with the literary finesse. I found that keeping your story line bare bones makes it easier to trace the relationship chain that variables require to work. Once you've got all your variables working, then fill in your story line with extra links to embellish.

Secondly, save each version of your story as you add parts (publish to file) to your hard drive. That way, if you go down a rabbit hole, you can simply go back to the version you know works. Twine can get a bit confused if you relate/delete links too many times/places and it simply may be easier to revert back and try again to an earlier version of your project than try to save  a super complicated one.

Thirdly, always think "Plan B". I got stuck on this project, unable to get an array variable to evaluate to a prompt variable? I'll need to research why this won't work (I "wood shed", pulling the code apart to run part by part,to display both variable results on the passage run in the browser, and could prove they returned the same value, but simply could not get the macro to evaluate so that they recognized each other). But, to avoid circling the drain, I simply changed my approach from variable as array (list of locations) to multiple if statements and instructing through the interface for the user to pay attention to what location was missing (using link to array = what's left?). Twine has some known "bugs", and you may want to check the Twine user forum to see what's currently targeted for "fix", but again, sometimes hard to know what other folks call their issues posted there to recognize if your issues matches what's been defined as a known bug!