You don't understand something until you've taught a teenager to teach a computer to do it.

Teaching with LightBot

2011 August 31

by Hélène Martin

Note: Andy kindly reminded me in the comments to at least mention LightBot 2.0. 2.0 has more levels, deliberately organizes them into categories such as ‘recursion’ and ‘conditionals,’ makes the turning direction a little more obvious and highlights the current execution step. I like that 1.0 is a little simpler but 2.0 really does have several good improvements.

LightBot is a programming-like Flash-based puzzle game. Players have access to several commands they organize in sequence to move a robot over certain tiles. I mentioned it a while ago in a post about creating computer scientists but I’ve noticed that though a lot of computer science teachers have seen it and liked it, they’ve shied away from using it in the classroom. I’ve enjoyed using it in with high schoolers in both an introductory breadth course and the AP Computer Science course. See UW’s CS Principles pilot blog for a nice narrative on how it was used in a college context.

It’s the basis for several good activities in the first few days of class — timely for many of us!

One logistical hurdle for teachers has been that the game is hosted on sites that are typically blocked by school districts. It’s possible to download the swf file (File -> Save As) and distribute it to students either locally or through a web or local file server. I hosted it on my course website. Please get in touch if you want to use it but can’t figure out how.

Pre-assessment

A teacher needs to know within a few days of a new course starting what knowledge, skills and misconceptions students are coming in with. I like to give a quick survey in which students self-report their comfort and enjoyment in different areas. Unsurprisingly, students who self-report success in algebra tend to more easily pick up programming but it’s not a perfect correlation.

I’ve found that watching students play LightBot has given me a really good sense of which students will pick up programming with ease and those who will struggle. I admit doing this with a bit of discomfort: I reject Knuth’s notion that only 2% of the population is comfortable thinking programmatically (Don Knuth, one of the ‘fathers’ of computer science, has been frequently quoted saying things like “[programming] takes a peculiar thought process, which I believe about one in every 50 people have, that makes them resonate with the computer,” found here). I don’t believe that programming ability is somehow an innate gift but I do recognize that certain students come in better prepared to think this way than others.

I tell students that I want to give them a taste of the kind of thinking that computer programmers use and I challenge them to complete as many levels as they can. Meanwhile, I walk around and observe how students interact with it. I immediately spot students who are not used to completing work on their own and turn to their neighbor as soon as they get stuck. I notice students who are very competitive. I see which students work through trial and error and which want to work out a full solution before trying it out. I’m always impressed to see students who take out a piece of paper to draw out a solution and I make sure to praise them for this practice when we debrief. Perhaps the biggest surprise for me has been seeing how many students have very poor spatial reasoning skills.

Discussing the experience

A teacher looking for the right things will get a lot of value out of exposing their students to LightBot. I think that whether the students get value from it will depend a lot on the debriefing period. Here are some of the questions I’ve discussed with students:

Did you enjoy playing the game? Why/why not? Most students seem to like it. Those who don’t like it find it frustrating and they’re the ones who will need the most support when learning to program. Many say they like it because it’s challenging. That’s a key thing to bring back when programming projects get tough.

What strategies helped you make progress? Trial and error to find out what each command does. Many say they write out a few steps and then verify that it works — they know that incremental development works. Many report putting themselves in place of the robot. This is a very useful debugging strategy. Some break down the problem on paper and work out a solution before turning to the computer, especially for the complicated later levels. These students will likely be scary good programmers.

What can you say about the language used by LightBot? It’s very limited, there’s no opportunity for ambiguity, sometimes the semantics weren’t immediately obvious (jump goes forward by 1 tile), functions are used to create new complex commands…

What are functions for? Reusing sets of steps that are needed multiple times, making command sets easier to read…

Coming back to it

A teacher can come back to students’ LightBot experience when formally introducing several tricky programming concepts including procedural decomposition and recursion. Again, read some of the UW’s CS Principles blog to see how they did this. I’ve found it a really powerful shared experience to draw from.

A lot of teachers use visual languages to make the transition into programming a little more gentle. I would recommend LightBot over Scratch, Alice or the like for that purpose because its more constrained nature lets us hone in on a few targeted skills. In fact, I’ve used it as a precursor to Scratch.

Similar game-like introductions to programming that I really like include Manufactoria and Picobot. I’ve tended to use these as supplements for more advanced students or as introductions to state machines since they don’t relate as closely to procedural programming.

Coming from a student of Ms. Martin’s AP CS class, I can tell you that this game was most helpful in understanding the basic ideas behind procedural programming. It was a great precursor to the more difficult aspects of programming languages, and a good partner to learning about methods and breaking complex scenarios down into a few steps.

Anyone figure out how to skip levels if a student has completed them but left the program and came back the next day. It seems like it makes them start all over. They can’t do all of the levels in one sitting and if they are on a network computer, they can’t just leave it up for later.

I generally have the opposite problem — my students all have access to whatever level the last person who used their computer got to. You must have your lab set up so that the machines get wiped every time a student logs out.

It’s possible to create accounts on Armor Games. The easiest would probably to let students each create their own account but you’d have to find out what your school’s policy about things like that is. Alternately, you could probably create a single shared class account (I haven’t tried it but it generally works out). That way, it would have access to levels up to the highest one any student has reached.

I downloaded a copy of lightbot 2 from Playtonic but it doesn’t seem to run properly in Flash Player 10. I’m running the player and browsing to the .swf file that’s stored on my hard disk. I don’t know if the .swf file is bad or if my technique is wrong.

I would like to have a local copy of this game on my server that students could run from their workstations.

I should add that I haven’t been able to run it locally either but only by re-hosting on a web server and accessing it through a web browser. Are you trying to share it through a file server? I don’t think that will work. E-mail me if you want a URL you could use.