Katie Salen's Take on How Games Can Change Education

Don't shoot the player while they're learning.  It's one of the keys to good game design as spoken by a veteran of the field, and adopted by Katie Salen in the context of education.  She spoke about that pearl of wisdom among many others during her recent talk at SXSW.

Drift Deck Joker Katie Salen / JulianBleecker

In video games, you don't want a player who is just learning the controls for the first time to have to also survive a barrage of attacks.  Learners need a safe environment to get the hang of things before they can be challenged.  The same should be true in a classroom.  A student shouldn't be in constant fear of being wrong while they are trying to first grasp something.

At the same time, failure is a good thing.  In games, trying and failing not only makes victory that much sweeter, but it ensures that the player has mastered a necessary skill before moving on.  Why in school do students have only one chance to pass a test? Why do they have to move on to the next topic even when they haven't mastered the previous one? I see this often when tutoring math: because a student doesn't have a solid base to work from, they get progressively more lost for each new topic.

The social aspect (and community) as well as the concept of sharing are important to learning.  There's no problem consulting fellow players of a particular game to get tips and tricks, or building a team of players who specialize in a particular skill but understand the big picture — yet the classroom parallel is often seen as cheating.  Even the typical spatial arrangement of a classroom, where students sit in rows facing the teacher, reinforces the focus on the individual.

These were the main takeaways from Katie's talk, as she summarized them:

• Design for friendliness
• Enable good practice (with failure)
• Support human-to-human exchange (qualitative feedback from peers)
• Keep challenge constant
• Make sharing seem like a gift
• Mind the gap (leave holes for students to fill)
• And, of course, don’t shoot the player when they’re learning

When you look at how games can change the face of education from this perspective, it starts looking a lot less crazy, and a lot more feasible.

Experiment: Teaching Computer Science With Stories

I've wondered in the past how important interactive storytelling might be in educational games.  The  potential to use story for more than just engagement seems high.  In just over a week, a colleague and I are going to run an experiment that will test how useful (not necessarily interactive) story is in teaching computer science concepts to complete beginners.

Stories You Like / Mountainbread

Our experiment is going to be done in the context of my mini-course, Computer Science and Games: Just for Girls! This year's class has 22 students, mostly in grade 8, so even if not everyone consents to participate (in which case we simply don't record their data), we should have a decent sample size.

I have always done many interactive activities in my mini-course, including several CS Unplugged activities.  I like to do the Image Representation activity when teaching computer graphics, and the Finite State Automata in the context of artificial intelligence.  For the experiment, I've been working on writing some stories we can embed the activities into.

The idea is this: We are going to split our class into two groups for both activities.  One group will do the activity as per usual, while the other group will do the story-based version.  The groups will swap for the other activity so everyone gets to see both styles of teaching.  During the activity we will record observations of the students (looking mostly for engagement), and after we will have the students do an evaluative worksheet to see how well they understand the topic.

I'm really curious to see what difference the story will make in the students' ability to understand.  I am guessing it will help, but I'm not sure how much.

Perplexing Problems in Educational Games

When it comes to presenting math problems in an engaging way, Dan Meyer knows his stuff.  From putting pseudocontext in its place to telling a math story with his 3 Acts curriculum, he knows what hooks kids and what turns them off.  His techniques are meant to work in K-12 classrooms, but why couldn't we use his ideas in the context of educational games, too?

Curious minds... / young_einstein

Dan recently wrote out his ten design principles for engaging math tasks.  Many of these could give insight into how to present problems in educational games such that players are drawn to a particular question without being told what that question is.  We want them to have an automatic desire to solve the problem, and figure out what tools they need to solve it, again without being handed the exact tools they will need.

This is the key behind the first principle:

Perplexity is the goal of engagement. We can go ten rounds debating eggs, broccoli, or candy bars. [references a debate, long since settled — dm] What matters most is the question, “Is the student perplexed?” Our goal is to induce in the student a perplexed, curious state, a question in her head that math can help answer.

Embedding problems into a game with this principle in mind could also lead to games that pull what Randy Pausch of Last Lecture fame called the head fake: they don't look like educational games on the surface, but they have real learning content.

There are a few principles that suggest games really are a compelling way to present these perplexing problems:

• "Set a low floor for entry, a high ceiling for exit. Write problems that require a simple first step but which stretch for miles." In a carefully constructed virtual world, these problems can literally stretch for miles.
   
• "Use progressive disclosure to lower the extraneous load of your tasks. This is one of the greatest affordances of our digital platform: you don’t have to write everything at once on the same page."  The presentation would be different (especially in a spatial sense), but of course you don't have to reveal everything at once in a game, either.
   
• "Make math social. More engaging than having a student guess whether or not the ball goes in is showing her how all of her classmates guessed also."  The magic of in-game networking could allow students to see other guesses not just within the classroom but all around the world.
   
• "Highlight the limits of a student’s existing skills and knowledge. ... That moment of cognitive conflict can engage students in a discussion of new tools and counter the perception that math is a disjointed set of rules and procedures, each bearing no relationship to the one preceding it." A player's abilities can be carefully tracked in a game while challenges are presented based on this assessment.

At the same time, it's not entirely clear how to apply some of the advice in a game because of either creative or technical limitations:

• "Concise questions are more engaging than lengthy ones, all other things being equal. Engaging movies perplex and interest you in their first ten minutes." While a game can engage the player quickly, what would it mean to have multiple problems presented throughout a game? How does having a large and complex story affect things, given that problems might end up being more spaced out?
   
• "Use stock photography and stock illustrations sparingly. ... It is hard to feel engaged in or perplexed by a world that looks like a distortion of your own." Will this be true of fantasy virtual worlds as well?
   
• "Ask for guesses. People like to guess, speculate, and hypothesize." How can guessing be effectively incorporated into a game without making it blatantly obvious?

I believe the idea of presenting problems in educational games in this way has a lot of potential, especially when considered in the context of constructing a good story for that game.  Of course, this goes not just for math, but any subject that requires problem solving (including computer science).

Winner of SCS TA Excellence Award

I found out this week that I was one of two winners for our department's TA award.  I was nominated for my term in the fall when I TA'ed the third year graphics course for our game dev students.

It's really nice to be recognized for the effort I put into the term, from running a course blog to offering informal tutorials before midterms.  It's also kind of cool to win because I helped set up the award in the first place while I was the TA Mentor.

As an added bonus, the undergraduate TA who won actually TA'ed for me the first time I taught as a contract instructor. How cool is that?

I'm heading to campus today for our end of year reception, where we'll both be recognized as winners.

The Craft of Research

"I still don't know what the f**k I'm doing." I was so relieved when recently I heard a superstar researcher, a full professor in computer science, say this about research.  I have so much to learn about how to be a good researcher.  That's why I was really pleased with this book I just finished reading: The Craft of Research.

I learned about this book through Steph.  It was assigned for a class on how to do research that she's taking for her Masters in Computer Science.  I always wished I had such a class, so I figured reading this book might be a good substitute.

There are three main topics that make up the core of this book: figuring out what you want to research, putting together an argument as a solution to your research problem, and finally writing an effective report on your solution.

In the first stage, you have to get from a general topic to a specific question you and your readers want answered.  From that question you find your research problem, something that readers think is worth solving.  Whether theoretical or practical, your problem consists of a situation or condition, and undesirable consequences caused by that condition.

Once you know your problem, you can begin to argue the solution.  Each argument consists of a claim, backed by a reason based on evidence.  You acknowledge and respond to issues you anticipate readers will have with your argument as best you can.  You can also use warrants when needed to illustrate how your reasons connect with your claims.  Each reason or piece of evidence might require a sub-argument of its own.

Finally, once you have the structure of your overall argument, you figure out how to structure the written report.  The advice on how to approach drafting the paper in this section seems really good, and I look forward to using it for my next paper.  There are a lot of specifics on how to revise sentences to be more understandable for readers, including what kinds of subjects your sentences should have and how to use the appropriate level of abstraction.

With lots of concrete examples and really clear writing, I highly recommend this book to everyone.  It is a great way to mechanize the process of research for beginners, yet helps seasoned researchers by bringing exactly what they are doing back into their consciousness.  I imagine that many of the tips within would be useful for any level of experience.  This will be a source I will return to often.

What Double Fine Adventure Means to Me

The very first feature-length games I played were point and click adventures.  I have particularly fond memories of King's Quest and Day of the Tentacle.  But those memories were just about lost to me as that genre of games became less popular over the years.  Enter Double Fine and their recent Kickstarter campaign.

(Image from Kickstarter campaign)

When I first heard about the campaign and realized that Tim Schafer was the mastermind behind both this campaign and my beloved Day of the Tentacle, I immediately pulled out my wallet.  I can't remember how far into the campaign that was; there's a good chance they had already pulled in quite a bit of money by then.  But as I got email updates about the progress, I started to realize that I just helped make a bit of history by contributing to the most funded Kickstarter project yet.  And I helped show publishers that just maybe, at least some of the time, they aren't as needed anymore to make money making great games.

So what does the Double Fine Adventure project mean to me? It means a return of a game genre that was welcoming and accessible to a wider audience that included me (and my mom, for that matter!).  It means feeling joy while waiting for a new game that I know I will play, rather than just watch.  It also means a chance to watch the development of that game through the documentary series that will detail the progress.

Speaking of which, I just watched the first episode of the series. Maybe it's the baby brain talking, but I had a little tear in my eye.  I couldn't help but feel so proud and humbled by Tim and all he has accomplished so far.  Can't wait to see more, Tim! Keep up the good work!

Quick Tips for Teaching Mini-Courses

I've been running my 'Computer Science and Games: Just for Girls!' course for Carleton's annual Enrichment Mini-Course Program for five years now.  And so at this year's instructor's luncheon, I was asked to share some advice for running a successful course.  Below are some of my key points.

#1: Don't be Afraid to Challenge the Students

These students, who are mostly in grade eight and occasionally high school, are much brighter than we tend to expect.  I have been teaching them computer science topics since the very beginning and am always impressed with how well they understand the concepts (proven by the puzzles or discussions we have after a lesson).  Computer graphics and artificial intelligence aren't exactly easy.

#2: It May Be Better to Stick to High-level Concepts

I don't try to introduce really specific algorithms and I never do any math.  Depending on the audience, I think you could certainly do some math, but so far my course has worked really well by sticking to high-level concepts.  It's only a week, so I figure it's better to deeply understand a few things than to barely understand many.

#3: Lecture As Little As Possible

My entire teaching philosophy is based on this.  It's even more important for this age group.  I am always looking for interesting ways to avoid talking to the students.  There are always things I need to tell them, but if I incorporate doing that with discussions, videos, activities, and so on, then it doesn't even seem like I'm lecturing.  Someone at the luncheon said a good rule of thumb was to lecture only for an hour.  I agree, but add that it shouldn't be all in one chunk.

#4: Look Online for Proven Activities

Thanks to the Internet, we can find proven lessons for almost every discipline out there.  I love using CS Unplugged activities for my course because I know they work.  See if you can find something similar for your course.

#5: Try New Things

This year, I'm running an experiment in my mini-course with the help of some colleagues.  We're going to test how much of a difference story makes in teaching computer science topics.  Why not try out some new teaching techniques in your own course? If you approach it with confidence, the students will likely be forgiving if it doesn't go as planned.  And who knows, maybe you'll get a research paper out of it in the end. ;)

Lecturing for a First Year Programming Class

I gave a guest lecture at Carleton last week. It was for the first programming class that both computer science and non-major students take, taught using Processing.  I seized the opportunity to use some of my somewhat less conventional techniques and "lecture" as little as I could.

50 minutes at a time by I, Timmy

I was lucky to be basing my lecture off of a very solid set of notes.  The professor who put these together taught me my very first programming class back in 2002.  (I still have a printed and bound copy of his notes from that class.)  In my guest lecture, I covered the first part of Chapter 8: Shared Data.

This is how I prepared for the class:

• First I glanced over the notes and then started to type up the source code described within.
• While I wrote out the code, I thought about what might be the best order to present it during class, and in what chunks.  (My order did differ from the order in the notes, which makes sense - written and oral communication are not the same thing.)  I saved individual files as I went along so that each file showed a bit more progress.
• I went through the notes again and kept a detailed outline of what I wanted to explain and what I wanted to get the class to do.
• I used my outline to create some simple slides (mostly images to help explain concepts) and some printouts I wanted to make for a couple of demonstrations.
• Finally, I made a much briefer version of the outline that I could refer to during the actual class so I didn't get lost (especially useful given how sparse my slides are).

This is actually the first time I used this exact method to prepare, but I think it really helped me get familiar with the content and figure out the best way to present it. I will definitely do it again.

Here are some of the interesting techniques I used that made my lecture a lot more like a tutorial:

• I explained a concept to students and then asked them to implement it in the code (I had them download a file with an initial bit of code to start with, and offered the individual progressive files in case they could not finish the task).
• I had students read code and explain to me what was going on.
• I had students hold signs and point to each other to emphasize how variables can refer to the same data and the implications of doing so.  I gave new signs or had them destroy the current ones to illustrate changing the data.
• I asked the class many questions and sometimes lead them to ask a question they would be able to answer by playing with code rather than hearing it from me.

I was very happy with how the class turned out.  It was risky doing it this way given that I had not been their instructor since the beginning of the term.  This was also a smaller class with about 30 people present, so I'm not sure how well these things will work with a larger group (I believe it could work, but I have not yet had the opportunity to try).

What kinds of techniques do you use in first year programming lectures?