Last weekend, I was invited to help with a session at CoderDojoDC that focused on Twine. CoderDojoDC is more-or-less the modern equivalent of the computer club I went to after school days in elementary school -- only instead of pirating Apple II games and messing around with AppleWorks and Logo, kids these days are learning Python and messing around with robotics. Progress indeed.
The day before had brought an inch of snow and 40-mile-an-hour winds, but fortunately had only left only frigid cold in its wake. After getting a little turned around coming out of the parking garage, I found the sometime-courthouse, sometime-Thingstitute, that CoderDojoDC now calls home.
It is quite something to enter a room and see a middle school-aged girl quietly working with software you created. Of course, at first I felt gratification and a sense of wonder at how far Twine's reach had grown -- but it also left me a little detached. Twine is bigger than me. It just is, and it has been for some time now.
I took a seat in the gallery. The workshop actually took place in the courtroom, no joke, with a giant screen mounted beside the judge's bench (that no doubt shows Exhibit A on weekdays) repurposed as one kid's workspace. The rest of the group worked at tables set up where the prosecution and defense would be. The kids ranged in ages from first grade (one girl, anyway, who wrote an adorable Twine story that began by interrogating the reader as to whether they liked cats or dogs) to perhaps late middle school, and at a rough count ran 55%/45% male-to-female.
After some opening administrivia, Melissa, the session facilitator who was kind enough to reach out to me in the first place, gave a quick introduction to Twine to the kids.
These were posters Melissa had created as reference points for the session. Again, a little strange to see design decisions you and others made long ago written out in schoolteacher handwriting as Fact. (Sure, I winced a little bit at the <font> tag, but can you really explain what <span style="font-size: 200%"> does in five sentences or fewer?)
I spoke to the group as a whole for a few minutes, prompted with questions from Melissa. One thing that was particularly nice to be able to say is that I originally wrote Twine in Python, the same language that the kids themselves had played with before. And then... we were off.
The kids seemed to understand the concept of a Choose Your Own Adventure immediately. The last time I gave a workshop on Twine, I worried that no one would even know what I was talking about if I mentioned CYOAs -- not so here. I'm not sure if it's because the interactivity of video games is easily translated to text, because of the recent CYOA reissues, or if somehow CYOAs have become part of our pop cultural genetic memory.
The other concept they grasped easily, interestingly enough, was [[double bracketing]] links to create new passages. It only had to be explained to them once. This crowd was self-selected, of course-- these are kids who are learning programming languages, so the concept of using funny characters to add behavior would probably not be foreign to them.
Still... one of the objectives I have had for Twine 2 for a long time was to implement a WYSIWYG editor. A first pass, where you click a button to turn text bold or italic, is easy enough to implement. But after playing with it myself, I'm not sure that it offers a significant improvement in ease-of-use, because macro code still remains. Take a look at this screenshot, for example. A standard WYSIWYG editor won't help tame this kind of rat's-nest (no offense meant, Mr. Sherman).
The logical conclusion would be to build a graphical interface for macros, something akin to Scratch, and doing that successfully strikes me as ambitious an undertaking as Twine itself. So I wonder if it is more effective for the time being to focus on making the process of writing code more pleasurable. A button to add bold formatting still seems useful to me even so, because even I have to look back at a Markdown cheatsheet occasionally. But we've never helped people create links with autocomplete, for example. Simple things you would expect out of any programming environment.
But I digress a bit. At the end of the workshop, kids who were so inclined could demo their work to the rest of the group. They showed themselves to be merciless game designers, to a degree that surely would bring a tear of pride to the eye of any gamebook designer from the 80's. Death was by far the preferred method of ending a non-optimal narrative branch. Memorably, one story asked if you would like to continue exploring the surface of Mars or return home (also located on Mars). If you choose to go home: (paraphrased) "You return to your family and starve to death." No, food had not been previously mentioned as a problem. A few stories even taunted players when they first started that they most likely would end up dead in-story.
Presumably no one attending that day had played Dark Souls yet -- so I wonder if it just a inherent property of choice-based games that death is the easiest route to the words THE END, or perhaps this is true of stories in general. Or maybe kids are just really bloody-minded. (Or... perhaps all these things are true.)
It was a wonderful experience overall, of course. One kid told called me over as he was working and told me he named the main character of his story after me. His first choice? Whether to go to a DARPA robotics competition. I'm sure you can guess what the right answer was.