Mark Engelberg: IF for home-schooled students

First, a bit about myself. I used to be a professional adventure game programmer and designer at Sierra On-line. Ten years ago, when my first child was born, I decided to stop working and become a stay-at-home dad. To keep busy, I signed up to teach classes about things I was passionate about (mainly games, puzzles, math, and programming) at a public school resource center for homeschoolers. I enjoyed working with homeschoolers so much, that several years later when my own kids turned school age, I decided to homeschool my own children.

One of the first classes I taught was an interactive fiction class using TADS 2. Really, the goal was to teach an introduction to object-oriented programming — the “interactive fiction” component was a secondary goal. I merely chose interactive fiction because I thought it would give the kids something fun to program, and excite kids who wouldn’t ordinarily be interested in programming.

A few kids enjoyed the class tremendously, but overall I felt the class was a bit of a failure. I discovered the hard way that one of the most important things in teaching an introductory programming class is to use a programming language/environment that gives extremely clear error messages. Those who came into the class with a certain amount of aptitude and interest in programming stuck with it, but many of the students got frustrated trying to get the syntax just right, and dropped the class.

My class notes for the TADS 2 class can still be found at the IF archive.

Over the years, I have continued to teach a variety of classes at homeschool centers, but have stayed away from interactive fiction. I have had much better success teaching programming via explicitly pedagogical environments, such as Alice and DrScheme.

This past semester, I decided to teach another interactive fiction class, but this time, to approach things from a very different angle. Rather than focus on the programming, I chose to put the emphasis squarely on the interactive fiction. How do you plan it? How do you write it? Along the way, I knew they’d get exposed to some programming concepts, but that would be merely incidental. To attract students, I posted flyers around the school (attached, adapted from Infocom samples), which worked well to drum up interest.

In planning for the class, I looked at TADS 3, to see whether it would be suitable. TADS 3 has come a long way from the version I used so many years ago. It has a full-fledged IDE, and other tools that make it a rewarding way for a programmer to write interactive fiction. It is my own preferred choice for writing interactive fiction. But ultimately, I decided that TADS 3 would end up making the class much more about programming than about interactive fiction, and that was something I wanted to avoid this time around. So in the end, I opted for a mixture of interactive fiction tools that would culminate in several weeks of learning Inform 7.

The class met once a week for 1-1/2 hours, with kids ranging from 5th to 10th grade.

Week 1: I showed up with a big stack of Choose Your Own Adventure books. I began by talking a bit about how humans have a rich culture of storytelling, and how people used to sit around the campfire telling stories. It would not be uncommon for a storyteller to pause and ask for ideas from the audience. “So how do you think she got into the castle?”, and then take one of the suggestions and run with it. Together the audience and storyteller would jointly create the story. How can an interactive experience like this be captured in written form?

At this point, I gave each student a different CYOA book, and gave them 20-30 minutes to read through it. I waited until every student had reached at least one ending. Then, I gave them each an opportunity to share observations about the stories, while I wrote down these observations on the board.

Some of the observations: Who is the main character? “YOU” are the main character. Stories are told in the “second person”. What does that mean? (brief discussion about 1st person, 2nd person, and 3rd person narrative. 3rd person is most common, 1st person is also common, 2nd person is rare). Why is it told in the second person? Makes you feel like you are there. Sometimes the character is not really “YOU”, it’s you in the role of someone with a specific background. What is the main genre of the books? Adventure. Why adventure? That way the choices are exciting. It wouldn’t be exciting if the story was about how you are walking down the street, and would you rather “look at the tree, or look at the telephone pole”? There are lots of endings. How many students encountered winning endings? How many encountered losing endings? Tally it up on the board, and look at the ratio. There is about 1 winning ending for every 3 losing endings. Is this ratio a coincidence? Probably not. Would it be fun if there were 16 losing endings, and only 1 way to in? No. Would it be fun if almost all the endings were winning endings. Probably not. So most likely, the author thought it through carefully and decided that this was a good balance that would make it feel like the choices had consequence, but not too frustrating. What do you think of this style of story? It’s fun to have choices, but sometimes it feels weird when the choices are limited, or aren’t something you’d really do.

How do you plan a choose your own adventure story? First, of course, decide on a setting, on the main character, and the basic idea of the story. I then showed them how to plot a choose your own adventure using a tree-like structure (contrasting this with the linear structure used to plan regular stories). The assignment was for each student to plan a choose-your-own-adventure story for next week, complete with a tree diagram. (# of endings = # of grade level).

Week 2: At the beginning of class, the students described for me their plans, and talked me through the various choices on their tree diagrams. Then, using a computer with a projector, I demonstrated how to use Adventure Book to create a choose your own adventure story on the computer (ignoring all the state-based inventory constructs and just focusing on how to make stories that mimicked the books). The students then had about an hour to implement their own ideas. To my surprise, all students finished within the hour (in part due to the extensive planning ahead of time, thus proving the value of up-front planning).

Adventure Book has a number of little quirks — things that can cause you to lose work if you enter things in the wrong order. Fortunately, I had demonstrated a “safe” way to enter things, and the students were pretty good about sticking to the workflow I had recommended. I was very relieved that nothing disastrous had happened (although I was a bit nervous when a couple of kids’ games wouldn’t compile — I eventually realized that they had used long filenames which adventure book couldn’t handle).

Week 3: I introduced RenPy, using a simple example “conversation” game I had constructed about an insult competition. I asked the kids to contrast the game with the choose your own adventure books. The obvious differences were the inclusion of graphics and music. Also, the game is told in the first-person, as an interactive conversation. Choices generally represent conversational choices.

Next I handed out a printout of the python script used to create the game. I asked them questions to see how much of the program they could deduce, just by looking at the program, knowing nothing about the language. For the most part, they were able to figure out what each line did. Then, using the printout as a model, they had the opportunity to write their own simple RenPy game. On this first day, I only expected them to display a background and character picture (using clipart I had provided), and one choice node. Most kids were able to do accomplish either the graphics, or the choice node, but only a few figured out how to do both before class time was up.

Week 4: One problem with tree structures is that they fan out, and pretty soon, you have way too many options to write. This week, I began to demonstrate tricks to keep the tree structure small. I showed a simple conversation with a pirate (he’s interviewing you to see if you’re pirate material). He asks you a series of questions. Your choice of answer gets a customized response, but regardless of your answer, he moves on to the same next question. After this brief demonstration, students continued working on getting a simple RenPy game up and running.

Week 5: Again, I demonstrated another technique for managing interactive conversations. This week’s demonstration was a conversation in which the player keeps looping back to the same conversation node, allowing the player to ask each possible question, until they choose the “Goodbye” option. Students continued to work on RenPy. Some were starting to get the hang of the Python syntax, but I sensed some definite frustration from other kids, who were consistently forgetting Python’s sensitivity to indentation, or forgetting where to put colons and quotation marks. Some were still having trouble remembering where to put the graphics files so that the python script could “see” the resource. Sensing the frustration, I told them all that we would spend only one more week on RenPy. I told them to plan a fresh story from scratch, to implement on the final RenPy class session.

Week 6: I had originally planned to culminate our weeks on RenPy with a discussion of how RenPy allows you to program choose your own adventures with a sense of state, in other words, that a decision you make early in the game can be remembered by the program, and used to affect the choices available or the outcome of a choice late in the game. But I didn’t think the kids could handle this, so I skipped this, and let them work on their own RenPy games. Interestingly, things seemed to really click for almost all of the kids on this final week, and all were able to complete their projects to a reasonable degree of success, so we were able to end on a positive note.

Week 7: I explained a bit about the history of “text adventure”-style interactive fiction, and how, through sophisticated computer programming, you can write interactive stories that give you the illusion of having a rather large number of choices. I put Sleeping Princess (a TADS game written by my kids, and programmed by me) up on the projector computer, and we played through it collaboratively. The kids would shout out ideas of what to do, and I would type them into the computer. The kids would often give commands that were either too specific or too general. Sometimes, I would type in those commands so they could see what the response would be. Other times, I would “translate” the command into something understandable by the parser, and would point out what I was doing and why.

The Sleeping Princess worked perfectly as an introduction, and fit very well into the time I had allotted. A few of the kids came up afterward and said it was one of the most fun computer games they had ever played. After playing the game collaboratively, we talked a little about the design principles of the game and how it contrasted with the other styles we had seen. (Back to second person; more choices; no losing endings; puzzles that stand in the way of winning). Then, I summarized on the board the main interactive fiction commands, and set them loose to play Mrs Pepper’s Nasty Secret (the winning entry in a competition I initiated to drum up suitable games for this class). They played the game individually, but students were encouraged to announce when they had achieved a scoring objective, and explain how they did it, so that others could benefit.

Students continued to have trouble figuring out how to word their commands in a suitable way, so I helped freely with that when necessary. Students did not get very far before time was up.

Week 8: Students continued playing Mrs Pepper. When they discovered the coded messages, I wrote them on the board, and a few students volunteered to come up and I guided them through the code-breaking process, so everyone could benefit. By the end of class, no student had completely finished, although a few were very, very close. The few that were close were so excited, they stayed after class to finish it up.

Weeks 9-12: At this point, I introduced Inform 7. Each week, I spent a half-hour demonstrating new concepts with a sample game that I gradually built in class. Then I would give them an hour to try out these ideas on their own. The final sample game is attached. Basically, we progressed from just doing room descriptions and connections between rooms the first week, to simple objects the second week, to simple rules on the third week, and a miscellany of advanced concepts on the fourth week (e.g., text variations, NPCs, and scoring). There were a number of things I didn’t even attempt to cover, such as creating new verbs.

The kids seemed to enjoy the whole idea of programming in plain English, and were especially relieved after the finickiness of Python regarding syntax. Of course, there was still plenty of confusion to be had with Inform 7. Some kids had trouble understanding that Inform doesn’t actually try to understand the contents of things inside of quotation marks. If their room description included the phrase, “The jungle is off to the north,” they wouldn’t realize that they also needed to say that the jungle is north of the beach again, outside of the quotes, so the computer could build the map.

The most common syntax problems were probably: 1. No space before a quotation mark, e.g., The description is”The jar is blue.” 2. Misspelling description, e.g., The discription is “The jar is blue.” 3. Missing a period somewhere. 4. Missing punctuation in a rule (colon, semicolon, etc.)

Unfortunately, the error reporting for most of these common errors had little bearing on the true source of the error, and kids were rarely able to diagnose and fix these problems without my assistance. This is similar to the trouble I encountered 10 years earlier with TADS 2, but fortunately, by this point in the class, the kids were pretty gung ho, so they dealt with these frustrations in stride.

Another common problem was that kids would inadvertently use names for objects and rooms that overlapped with each other and/or reserved names that would throw off Inform’s parsing. For example, a “hot dog stand” and a “hot dog”, or “Inside of the closet” and other conflicts like that. There are some power-user foolproof mechanisms for fixing this (like giving every object a unique nonsense name and then using the understands construct to introduce vocabulary terms), but I feared this would be too confusing, so I found myself constantly showing them ad hoc techniques to fix these problems (renaming the object, or sometimes using the “called” syntax). Again, kids weren’t really able to internalize and apply these fixing techniques on their own.

Overall, all of the students were eventually able to write rooms and objects. Most of them understood rules, but weren’t able to apply them on their own. A few of the students tried to implement scoring in their games, and ran into many problems with the ways that “the first time” constraint interacted with rules in non-intuitive ways, making scoring more difficult than expected. For example, if you make a rule to get points after the first time something is taken, then if some failure occurs the first time you take the object, you can never get the points because the later, successful taking of the object no longer counts as “the first time”.

When I constructed the sample game, I assumed that we would never get to many advanced concepts, so I strove for simplicity over scalability. For example, my own experience suggests that “Instead of” rules are very fragile, because they occur before feasibility checks. Most “instead of” rules break if you put a chair in the room, and try to perform the action while sitting in the chair. The instead message prints, but then you receive a message that you can’t do that while seated. Nevertheless, I used “instead of” rules heavily in the sample game, because they are the easiest to understand, and I didn’t think the students were likely to implement chairs or other similarly complicating objects. Other “naive approaches” like this can be found in my sample game.

Week 13: Up until now, I let the students create without any planning, just to exercise what they had been learning about Inform. This time, I gave the students an entire class session to plan their final project. I expected a map, and a verbal description of the game. Most students picked something way too ambitious, and I had to help them scale back the scope of their project.

Weeks 14-15: Students worked on their own final Inform projects. None of the students achieved anything near a “professional-quality” game, accepting a wide range of inputs. But most of the students completed a simple game with a reasonable winning path. A few students had enough time leftover to go back and polish spelling and grammar, but many did not.

Week 16: On the final day of class, I gave the students an opportunity to fill out anonymous ratings for the class. We then finished by playing an interactive storytelling game called “The Adventures of Baron Munchausen” which I adapted for use with kids. Basically, each person takes a turn drawing a tall tale card (e.g., “Tell us how you came to discover Atlantis, and why it sank ten minutes later.”), and telling that tale. In the meantime, others interrupt with various elements that the storyteller then tries to incorporate into the story. It seemed like a very fitting end to the class, reminding the students that ultimately, interactive fiction isn’t about technology, but about the interplay between a storyteller and his audience.

By all measures, the class was a resounding success. No one dropped the class and the class received very high ratings from the students. Perhaps the biggest disappointment was that the average rating for “How much did you have the opportunity to exercise your creativity?” was only a bit over 3 on a scale from 1 to 5. This surprised me. Almost every class, 2/3 of the time was spent on the students programming their own creation, with almost no constraints. How much more creative can you get? The only explanation I can think of is that maybe there was too big a gap between what the kids wanted to create, and what they were able to create.

I had also asked the kids to state their favorite part of the class, and whether they felt we should have spent more or less time on a given topic. The favorites were pretty evenly distributed. Some preferred Adventure Book, because it was the easiest. Some preferred RenPy, because they enjoyed working with graphics. Others preferred Inform, because it was the most expressive tool. However, interestingly, no one asked to spend less time on any particular thing. All the requests were that they wished to have spent more time on their favorite thing, but without sacrificing time spent on something else.

– Mark Engelberg