Terrafugia's flying car. No, really.

Last week, I attended TiECON East as a finalist for the TiE Challenge accelerator program. One of the most interesting keynotes was given by Carl Dietrich, a young aerospace engineer and entrepreneur who leads Terrafugia -- a company building a flying car.

Dietrich joked in his talk that flying cars are featured seemingly every year on the covers of Popular Science and Popular Mechanics. But none of these inventions have been taken to market. Terrafugia is serious about approaching this challenge, which is multifaceted. Besides the engineering problems associated with building a vehicle that can drive on city streets and take off from a runway, there are also significant regulatory and business issues that must be overcome.

Dietrich laid out a very convincing business case for this type of vehicle, which he said would cost $270,000. The savings for pilots comes in the fact that storage fees and inconveniences associated with bad weather can be avoided (you'll never be stuck at a remote airport again because of bad weather!). His team is also working on the regulatory issues (he and several members of the senior management team participate on FAA advisory panels and standards groups). But the plane, the Transition, was the star of the show. He showed a flight video and it was hard not to be excited. Here's what it looks like:



Note the fact that it works on normal unleaded gasoline, not airplane fuel. And it fits in a garage. I can't wait to see these in the skies.

Teaching Computer Science Through WoW Scripts

Tweet

The following paper is a curriculum for learning basic computer science concepts using World of Warcraft and the scripting language Lua. I wrote the paper with two other MIT students while taking Eric Klopfer's course "Computer Games and Simulations for Education and Exploration" (11.127/CMS.590) in March, 2011. It was originally published on my MIT site. I am archiving it here for anyone who is interested in learning how video games can be used for education. See "A curriculum for learning computer programming in WoW" for background on this project.


Curriculum: Teaching Computer Science through WoW Scripts

Andrew Hsiao, Ian Lamont, Michele Pratusevich

CMS.590: Professor Klopfer

1 March 2011

Introduction

For decades, games have introduced young people to computer programming. Early exposure to programming games has been a stepping stone to careers in computer science and technology-related entrepreneurship. There are many well-known examples. Long before he built Facebook, Mark Zuckerberg reveled in creating computer games with his friends, and Salesforce.com cofounder Marc Benioff got his start in the computer industry as a teenage designer of games for Atari home computers.

But even among young people who don't become programmers or found startups, there is a widespread awareness of the role in programming in creating games. There comes a point in the life of a typical primary school student that he or she will wonder how handheld, console, or web-based games are made, and the answer will come back that someone - or a group of people - entered a series of instructions into a computer to make it display images, play sounds, and perform functions that make up the gameplay. Some of the more dedicated gamers or curious tinkerers may be compelled to take things a step further by designing their own games, or modifying existing games ("modding") to extend the gameplay in some fashion. In doing so, these youths learn many elementary programming concepts, including computer languages, software tools, and fundamental computer science building blocks such as variables and functions.

Many others, however, will never take that next step. They will be aware of the role of programming in creating games and other software, but will never learn specific concepts or the practical aspects of computer programming.

Teaching Computer Science through WoW Scripts is designed to help non-programmers bridge the gap. The following series of four exercises is designed to be the beginning of a course in teaching high-school students basic computer science concepts, as well as critical thinking skills, using the online role-playing game World of Warcraft and the scripting language Lua. The curriculum is aimed at teenagers who have never been exposed to computer programming or played the game, although those with some experience may be able to develop more advanced scripts to use in the game. Students will learn how computer languages work, including core concepts such as if statements, loops, and variables.

With these foundations, students can then learn more complicated programming concepts such as functions to develop their own complex customizations of WoW. In a more comprehensive computer science curriculum, the concept of saving scripts that can be run much more easily using macros would be explained. For an advanced curriculum, the creation of add-ons would provide a practical purpose to programming and scripting. However, because add-on creation is involved and complicated, it is not one of the exercises described here.

Definitions

World of Warcraft (WoW) is a sword-and-sorcery fantasy world that lets anyone with a PC or laptop and an Internet connection battle monsters, find virtual treasure, and play with other people who are online at the same time. The world is not unlike J.R.R. Tolkien's Lord of the Rings, or the fantasy game Dungeons & Dragons. It was launched by Blizzard in 2004, and is one of the top online role-playing games, with millions of users in the United States, China, and elsewhere.

Lua is a powerful, lightweight programming language that is known as a "scripting language." Scripting languages enable control of an application (in this case, World of Warcraft) but Lua has also been used for other games, industrial applications, and consumer hardware platforms.

"Scripts" are small computer programs that perform a very specific function. Typically, they are a very precise set of instructions that the software environment (i.e., WoW or some other program) can understand. Sometimes they are as short as a few sentences of text. In a game like WoW, a script might display extra information about a monster that is attacking a player, or help a player find a new route to a certain destination. Many first curricula in computer science use scripting languages to teach fundamental computer science concepts because they have more gradual learning curves than other kinds of programming languages. Scripts do not require installing compilers and interpreters that come with more complex programming languages. After learning basic programming concepts in a scripting language, more complicated programs can be written using multiple scripts.

Specific computer science topics, exercises, and outcomes in the WoW programming curriculum are listed below.

Why WoW?

Instructors may wonder why a gaming environment is being used to learn programming concepts, as opposed to textbooks and traditional classroom lectures. Besides the obvious interest that games hold for young people (according to a recent survey, 80% of American teens aged 12-17 own a game console ), the practice of experimenting in a game world reinforces what James Paul Gee refers to as the Probe, Hypothesis, Reprobe, Rethink Cycle. As noted by Gee in What Video Games Have To Teach Us About Learning And Literacy, this cycle is required to learn complex and fast-moving video games in immersive 3D environments, like the one found in WoW. The four-stage cycle works as follows:

1. The player must probe the virtual world, which involves looking around the current environment, clocking on something, or engaging in a certain action.
2. Based on reflection during and after probing, the player must form a hypothesis about what something (a text, object, artifact, event, or action) might mean in a usefully situated way.
3. The player reprobes the world with that hypothesis in mind, seeing what effect he or she gets.
4. The player treats this effect as feedback from the world and accepts or rethinks his or her own original hypothesis.

But the process is not limited to learning how to survive an attack by a monster or find a certain treasure in a video game. The Probe, Hypothesis, Reprobe, Rethink Cycle can be applied to a variety of extracurricular learning situations. It is part of humans' innate ability to recognize patterns, self-reflect on outcomes based on success/failure feedback cycles, and derive powerful learning experiences. "It's how children learn," Gee writes, "when they are not learning in school."

For the WoW programming curriculum, the Probe, Hypothesis, Reprobe, Rethink Cycle will take place on two levels. Learning to program requires cycles of experimentation and testing on the code, in order to make sure it works and improve the functionality. There is also the effect of the scripts on the gameplay itself, which students can also probe and test in a shared environment with their classmates. Some students may want to share their "mods" with each other, or cooperatively work on more complex tasks (for instance, dividing up coding and testing responsibilities). Such behavior adds to the learning experience and encourages critical thinking and teamwork in a shared environment of peers.

Tools you will need

Students will need to have World of Warcraft installed on the laptop or PC they are using for class. They should register their game, create a player, and experiment with the world before starting the exercises. We recommend that each player spend at least three hours in WoW and reach at least level 3 before starting the first exercise. Before attempting an exercise, students' characters should be in a town or other place where they will not be attacked or disturbed.

The basic tool needed to create scripts in Lua is the WoW game itself. Very simple yet powerful scripts can be created right in the chat box of WoW. The first exercise describes in some detail how this is done. For creating more complex scripts, a basic text editor like Notepad (that comes standard with every PC) or TextEdit (included with every Mac) can be used to edit the scripts before pasting them into the WoW chat box. Students will not need to use external text editors (outside of the WoW chat box) to create scripts until they are at a level where they are using macros to hold their scripts.

Before starting on the exercises, students should be aware that there are a plethora of resources available online about writing Lua scripts, macros, and add-ons. World of Warcraft has built-in functions that are available through an "application programming interface" (shorted to API) that can be used in any script. An API is just a collection of functions and properties of the language that can be used by the programmer. Information about the WoW API can be found here.

Summary of class exercises

1. Beginning programming concepts and Hello World

Creating a simple program that displays the text "Hello World" is a long tradition in teaching new computing languages to students. In this exercise, students will use the Lua scripting language to display "Hello World" in the WoW chatbox.

In the first activity the student will learn how to accomplish one of the simplest tasks in programming: outputting a message. With this program, the student will be able to "print" statements. Explain to the student the meaning of "print" in programming jargon: being able to "print" refers to being able to output text to some sort of interface the programmer can see. When programming in Lua in World of Warcraft, that interface is the chat box. An important thing to note when printing to the chat box is that whatever is printed will not be broadcast to the world. Rather, it is only printed in the chat box of the user who is running the script. The student should be shown this script to print a message to the chat box:

/script print("Hello World!");

Take a look at the components of this program. First the statement "/script" is typed into the chat box to denote the start of a Lua script. All scripts you type into the chat box will start with this statement.

Next there is the statement "print". This function is provided by the World of Warcraft API to give the programmer the opportunity to print statements to the chat box. Built-in functions can be used in any program to accomplish tasks the programmer does not want to hard-code himself. Many of the built-in functions in any environment or programming language accomplish tasks that would be very difficult to code by the programmer.

When a function such as "print" is used by the programmer, it is referred to as a function call. The function calls using the built-in functions in WoW are straightforward - the function call "print("Hello World!")" takes the chat frame at the bottom left of the screen and adds the message "Hello World!" to it.

The ""Hello World!"" between parentheses immediately after the function is what is called the argument of the function. Arguments are parameters that are used by the function to accomplish a specific task and usually vary between function calls. In this particular case, the text can be changed to anything that the programmer wants to be output to the chat box.

The semicolon at the end of the statement denotes the end of a logical statement in the script. A semicolon is required at the end of every logical statement. This is a confusing concept to first-time programmers, but hopefully the examples provided in the exercises will give more insight about this. It is up to the discretion of the teacher how much they want to enforce and encourage the use of semicolons.

Note that the text must be put between quotation marks to be recognized as a valid text input. Each function requires its own special formatting for the arguments, but for outputting text to a chat box, the text must be enclosed in quotation marks. Notice how the text is printed on one line in the chat box. To print something that spans multiple lines, use the sequence of characters "\n" (it means "new line", back from the days of the first programming languages). When this sequence is inserted into a block of text, the text that comes after it will be on a new line. So the code:

/script print("Hello \n World!");

will print "Hello" and "World!" on different lines. Finally, the statement is closed with a semicolon. In Lua, a semicolon denotes the end of a line of code. When typing scripts into the chat box, the semicolon is necessary for the chat box to understand that it is finished running the script and can begin taking normal chat box input again.

Text is not the only thing that can be printed to the chat box. Text in the context of programming is referred to as a string. The reason that the text must be put between quotation marks in the print statement is that the script only recognizes strings when they are put between quotation marks.

Strings are only one type of input that the script recognizes. If a script sees a number, it treats it differently than a string. A whole number in the context of programming is referred to as an int (short for integer). Ints can be used in arguments of function calls, but they do not need to be surrounded by quotation marks. This idea of strings and ints brings up a more advanced concept in computer science that would be revisited in a more advanced exercise: the idea of types of input that the script sees. The students learning computer science through WoW Scripts do not need to understand the idea of types, but they should know that the script treats numbers and text differently.

Using print statements are useful in programming for a variety of reasons. When needing to test outputs of programs that are more complicated or wanting the user to see a certain message, print statements are a simple way of achieving this goal.

As an additional exercise, a student should modify the above code to print his or her name into the chat box. Modify the code to print numbers as well - keep in mind that numbers do not need to be surrounded by quotation marks.

2. Conditional statements

This section is intended to introduce students to basic control flow using if statements. Explain to students what control statements do: if statements take a conditional statement, and then execute a specific section of code depending on if the conditional statement is true or false. Present the following script to the students:

if (IsPartyLeader()) then

print("I am the leader of my party!");

else

print("I am not the leader of my party.");

end

In one line for in-game use the script would look like:

/script if (IsPartyLeader()) then print("I am the leader of my party!"); else print("I am not the leader of my party."); end;

"IsPartyLeader()" is a function like "print", except this function does not take any arguments because it does not need information from the user to perform its task. All the information it needs is automatically gathered from the game. In this case, it will be true if the player calling the function is the leader of a party, and false otherwise. The reason for the "()" at the end of the function call is that all function calls must contain these parentheses. However, not all function calls require arguments between the parentheses.

Have the students log on to WoW and pair up. Have one student in each pair create a party and invite the student they are paired with. Then have both students run the script and verify that the one that is the leader has the message "I am the leader of my party!" in their chat window and the other student has the message "I am not the leader of my party." Then have the second student invite the first student to a party and have them both run the script again, and verify that both students have the other message printed out to their chat window. After the students have had a chance to try it out themselves, walk them through the execution of this script, pointing out how the control flow differs for each case, and how the game decides which message to print.

Now have the students modify the script so that if they are outdoors, the script prints out "I am outdoors!" otherwise the script prints out "I am indoors." The relevant function you should have them use is the IsOutdoors() function. The end result should look similar to the following code:

if (IsOutdoors()) then

print("I am outdoors.");

else

print("I am indoors.");

end

To run the script in-game the following should be typed into the chat window:

/script if (IsOutdoors()) then print("I am outdoors."); else print("I am indoors."); end;

To have students test out their scripts, have them use their hearthstones to get to a town or city, and then stand outside the doorway to a building. Run the script while outside, then walk into the building and run the script again. The two messages should print out into their chat windows.

At the end of this module students should understand how if statements work.

3. Variables

This section details how to introduce students to variables, both in terms of what kinds of variables there are (types) and how to use them in scripts. The concepts of ints and strings were introduced in the first exercise but are given a more thorough (but not complete) examination here. Explain the concept of variables to students: variables are placeholders for other values, and are usually used to allow for easier manipulation of whatever data you are working with. Show the following code snippet to the students:

local a=3;

local b=4;

print(a*b);

When showing how to translate the expanded code into the one liner for in-game usage, make sure to point out that since we are putting all of the code into one line, we have to include a semicolon between the statements as a delimiter for where one statement ends and the next begins. The in-game code would be the following:

/script local a=3; local b=4; print(a*b);

Have the students run the script on their own machines. Next explain the difference between local variables and global variables. Local variables only exist for the one single run of the script, while global variables persist even after the script has finished running. Local variables must be specifically declared as such; if there is no "local" keyword before the variable is defined, the game will assume you want the variable to be a global variable. To demonstrate, have the students enter the following:

/script print(a); print(b);

They should get "nil" as a result both times. "nil" means that there is nothing there, that the game thinks the variable is undefined. Now have them run the first script with the local keywords taken out:

/script a=3; b=4; print(a*b);

And then run:

/script print(a); print(b);

This time they should get "3" and "4" printed to their chat boxes instead of "nil".

Finally we want to teach the students that there are different types of variables. This is explaining with an example the difference between an int and string that was introduced in the first exercise. Show them the following script and ask them what they think will happen:

local c=2;

local d="Hello, World!";

print(c*d);

After having them guess, have them run it in-game:

/script local c=2; local d="Hello, World!"; print(c*d);

They should have nothing print out at all. This is because "c" is representing a number while "d" is representing a string, and the game has no idea how to multiply a number to a word; it only knows how to multiply if it has two numbers. When something goes wrong in a "/script" command, the game will simply stop running the script, which is why nothing is being printed out.

At the end of this exercise students should understand that variables are placeholders for other concrete values, and that there are both local and global variables as well as different kinds of variables. As an exercise, have the students do some basic calculations with print statements based on the experience points and money awarded by a quest. An example of such an exercise would be printing the name of a quest and then the ratio of the number experience points to the number of money awarded by the quest.

4. Loops

Loop statements repeat a specific computing task. By the end of this activity, students will be able to create a loop that goes through their players' extensive inventories of weapons, armor, treasure, and other objects, and displays them in the chat box.

The outcome for this second activity is to teach students the basic programming control flow of for loops. A for loop is a control flow used in computer science to complete a repeated action. Automating this process instead of typing out the same line of code or executing the same action multiple times saves time and effort. A simple version of a for loop can be used to for example print 10 messages to the chat box:

/script for i = 1, 10 do print("Again!") end;

What is happening in this script is simple: the for loop syntax counts from 1 to 10 inside the loop, executing whatever statements are between the "do" and "end" tags. There can be more than one statement between the "do" and "end" tags, since any action can be executed inside of a loop.

The use of "i" in the for loop is called a counter. It is a variable (taught in the previous activity) that keeps track of the number of times the for loop has been executed. To change the number of times the for loop is executed, simply change the numbers after the variable "i". This variable can be used inside the statements of the for loop (between the "do" and "end" tags) to do any number of things - for example, you can print the variable itself inside the for loop:

/script for i = 5, 8 do print(i); print("\n"); end;

And the script will print the numbers 5, 6, 7, 8 in the chat box on separate lines. There are many things you can do with for loops in the context of the game. For example, try the following exercises:

1. 6 times, if the player is the party leader, print "I am the party leader!"
2. Challenge: using online resources and the World of Warcraft API to write a script that loops through all the items in your bags and prints out their names in the chat box.

Timescale

Students should be level 3 or higher in World of Warcraft and have active accounts prior to starting the lessons. Explaining some of the basic definitions (Lua, script, chat box, etc.) and discussing the test environment (i.e., WoW) should take no more than 45 minutes. Each exercise should take one 45-minute class session to complete, although instructors may want to devote more time to certain lessons if students need more time to experiment with the scripts.

An important thing to note about learning programming is the self-help portion. To become proficient programmers knowledgeable about programming concepts and execution, students should spend time experimenting with writing their own scripts. The more time students spend on the exercises, the better of an understanding of computer science concepts they will have.

Once the lessons are complete, some students may be interested in progressing beyond the curriculum exercises. A good place to start is the WoW API, which will provide many interesting built-in functions to experiment with. To get started with macros, please visit http://www.wowwiki.com/Making_a_macro .

Assessment

The simple exercises that follow will reinforce some of the basic concepts described above. Any subset of these exercises can be used as an assessment of concepts learned. The teacher can decide which exercises to use as an assessment and which can be used as additional practice assignments. Exercises are grouped by concepts. In all exercises, students should be encouraged to test the scripts they have written. For example, for the first conditional statement exercise below, students should be encouraged to run the script first when they are targeting another character and then later when they are not targeting another character.

Built-in functions:

• Ask the students to use print to display the first names of three of their classmates on three separate lines in the chat box
  
  Example solution:
  
  /script print("Andrew"); print("Ian"); print("Michele");
• Ask the students to use print as a calculator to calculate the amount of copper they have in their possession. The conversion rate is 1 silver piece equals 100 copper pieces. They should just manually open their bag to see how much silver and copper they have, converting and adding the numbers to calculate the total amount of copper they have.
  
  Example solution:
  
  /script print("I have ");print(3*100+52);print(" copper.");

Conditional statements:

• Using the WoW API, find the relevant functions to accomplish the following task: check to see whether you have a character targeted. If you do, print a statement saying so. If you don't print an alternate statement.
  
  Example solution:
  
  /script if(UnitHealth("playertarget")~=0) then print("TARGET ACQUIRED!!"); else print("I don't have a target..."); end;
• Using the WoW API, find the relevant functions to accomplish the following task: if you are swimming or not swimming, print a relevant statement.
  
  Example solution:
  
  /script if(IsSwimming()) then print("I am swimming."); else print("I am not swimming."); end;

Variables:

• Design a simple script using variables and the built-in function GetMoney() to print the number of silver pieces in your possession. This is building on one of the additional exercises from the built-in functions - automating finding the amount of money you have in your possession instead of having to look in the bag yourself. Use print() to give context to the number displayed. GetMoney() returns the number of copper pieces in the player's possession. The conversion rate is 1 silver piece equals 100 copper pieces.
  
  Example Solution:
  
  /script a=GetMoney(); b=100; print("You have "); print(a/b); print(" silver pieces");

For loops:

• Design a script that prints out how much money you would make if you sold every item in your backpack. Use the following code snippet to get the sell price of an item:
  
  local itemSellPrice=select(11, GetItemInfo(itemID));

Every time the previous line of code is run, the variable itemSellPrice will contain the sell price in copper of the item with the ID of itemID. The function GetContainerItemID will be useful here; read its documentation in the WoW API.

• Example solution:
  /script local total=0; for i=1,9 do local itemSellPrice=select(11,GetItemInfo(GetContainerItemID(0,i))); total=total+itemSellPrice; end; print("My items are worth"); print(total); print("copper.");

Note that the ending index of the for loop must equal the number of items in the student's backpack, and that all the items must be packed as tightly towards the top of the backpack as possible (i.e. there can be no gaps).

---

This document was co-authored by MIT students Andrew Hsiao, Ian Lamont, and Michele Pratusevich for 11.127/252/CMS.590, Computer Games and Simulations for Education and Exploration in March, 2011.

Educational iPhone game development: Our experience with Egg Drop

It's an exciting feeling to be a part of a team that creates something special. It's even more exciting when you see early users not only getting a kick out of the product, but asking to use it again and again.

That was our experience with Egg Drop on the iPhone, an educational game and our student team's final project for 11.127/252/CMS.590, Computer Games and Simulations for Education and Exploration (see also my post on an earlier student project from the same class, "A curriculum for learning computer programming in WoW"). Our assignment, which built on nearly three months of instruction, theory, readings, and other projects, was to design and produce a digital game that is playable for 15-20 minutes. "You should identify clear learning goals and map them onto game dynamics," we were told. To actually develop the game, it took about 24 days from the initial ideation sessions to the final presentation at class demo day.

There is a lot of flexibility in the term "digital game," and the half-dozen student teams in the class pursued all kinds of ideas. On demo day, we saw Terminus, a text-based adventure to teach terminal commands ("Zork meets terminal," was one way of describing it). Another student team created a PC game called Rocketmouse that taught children the fundamentals of gravity.

The class had a lot of Course 6 undergraduates, including some who had written games in the past. But the instructors (Eric Klopfer and Jason Haas) made an effort to balance out the teams with experienced programmers and people who couldn't program, but were able to handle other tasks.

Coming up with an Egg Drop game idea

Our team didn't go into the project thinking that we would make a mobile game. The ideation process started with the class brainstorming on potential learning topics; those ideas were put on a whiteboard and then people could choose which team they wanted to join. Inspired by a recent engineering documentary about the construction of a helipad on top of a wind-blown skyscraper, I suggested doing some sort of construction-based game that would teach basic architectural concepts. At the time, I was thinking of something on a PC or the Web, which would allow for a more sophisticated interface.

Alec, a Course VI classmate with whom I had worked on a “digital gates” board game earlier in the semester, was interested, along with a few other undergraduates. We discussed how to improve the concept. One of the first suggestions was to do it as an iPad game. The idea was to use a touch-screen interface to build a skyscraper, and then testing the strength of the construction with various environmental forces such as wind, earthquakes, and other disasters. Alec came up with a clever twist: How about turning the game into a variation of Angry Birds? Instead of being the birds trying to get at the pigs, the player would be the pig, trying to protect the egg from being knocked down, by building a strong-enough structure.

The “Reverse Angry Birds” proposal (also known as “Reverse Upset Avians”, or RUA) was put on a whiteboard with about a dozen other ideas. It got some votes from the class, and was chosen as a finalist project. Five people joined the team in all, and we started to refine the idea and discuss the practicalities of implementing them.

One decision that we had to make right away concerned the platform. While the iPad sounded promising, there was a problem: Aside from me, no one had an iPad, which would make life difficult for our developers when it came time to test the app. The iPhone seemed like a better idea, because:

• Three of us had iPhones or an iPod touch
• Three of us had Macs, which meant we could work in Xcode, Apple’s developer tool for the iOS SDK
• Alec had experience developing games and developing on the iPhone platform, and was also familiar with a 2D game engine for the iPhone called cocos2D.

The team agreed that the iPhone/Xcode path was the way to go. Clearly, myself and the one other person who were not Course VI would be unable to build a game, but there was room for us to do “code-like” activities, ranging from building artwork and sound files to creating levels in XML. I was capable of doing those tasks (and had some prior experience with level design in our 6.898/Linked Data final project), and could do user testing/QA (I had two young subjects who were willing to pitch in, as described below).

In the proposal document submitted to our instructors, we described the game as follows:

Egg Drop is a physics-based game designed for the iOS platform that attempts to teach basic intuition of physics and stable structures.

Because it is an iOS game, the only way to play Egg Drop (barring a release on the Apple app store) is to download and compile the source. The source of the game is hosted publicly on Github and can be found at:

https://github.com/alect/Digital-Egg-Drop

Learning Goals:

• Gain a rudimentary understanding of physics, construction and other principles involved in building structures
• Learn strategies for building stable structures that can survive the elements.
• Learn to use resources in an optimal way to meet construction goals.
• Develop the hypothesize -> experiment -> redesign strategy of designing, which is a useful skill in many wider disciplines than construction. The flow of the game should lead the player to use this strategy inherently, and hopefully bring the strategy with them from the game.

Prototyping and game-testing Egg Drop

Our plan was approved, and we got started on RUA. MIT has built up a culture around experimentation and prototyping and we all got to work pretty quickly. Alec was the lead developer, and took on tasks relating to integrating the physics engines, building the objects and resource manager, and creating a sound engine. He built a working prototype within a few days and uploaded it to github, which let those of us with Macs download it and try it out in Xcode’s iPhone simulator.

Another Course Sixer, Sarah, hadn’t used Xcode or Objective C before, but got up to speed very quickly. She was responsible for much of the final design as well as an in-game tutorial, which really helped make the game more appealing (you can see the tutorial in the gameplay video at the bottom of this post). She also created the system to import levels in XML format, which made it easy for me to do some age-appropriate level design and implementation on my own for our user testing -- before the XML engine was built, in order to alter levels during testing I had to change values in arrays and arguments in ResourceManager.mm. These changes were difficult to share with the rest of the team and prone to error, so Sarah’s work was very helpful. A third Course Six concentrator, Stephen, didn’t have a Mac (a requirement for Xcode) but worked on artwork, sound files, and documentation. The other member of the team worked on level design.

The game evolved from our original vision of creating a variation of Angry Birds. Creating the gameplay and artwork for the pigs and birds would have been extremely difficult and time-consuming (we only had a few weeks before demo day on May 10). We settled for a slimmed-down version of the game in which the goal was to build a structure that would protect a single egg from an onslaught of natural disasters at the end of each round. For instance, the kid-friendly level #3 used the following XML as inputs:

On the screen of the iPhone simulator, this translated to an egg resting on the plain at the start of the game (posx and posy describe its starting position). The player could place, in order, two vertical wooden planks, a horizontal straw block, and a horizontal brick, before the disaster (a meteor falling from the sky, directly on top of the egg) occurred. The only way to survive: Placing the two vertical wooden planks next to the egg and the horizontal brick resting on top of the plank, over the egg. Any other combination resulted in the egg breaking and “game over” for the player.

Changing the name of our Egg Drop project

As the game evolved, we dropped “Reverse Upset Avians” and started calling it EggDrop. It was an instant hit with my kids, even before we had meteors and earthquakes. The simple physics of placing planks around the egg was entertaining enough in sandbox mode (see screenshots, below). But when better artwork, different building materials, nails and other elements were added, it was addictive. My younger child in particular would ask to play it when he came from school, and after I came home from a long international trip, one of the first things he asked to do was play the game on the iPhone simulator.

One interesting element of game design that came up with the Egg Drop project was the target audience. I thought we should really be clear who we were targeting at the outset. Segmentation and “Total Addressable Market” exercises are part and parcel of the Sloan way in classes such as New Enterprises. But we ended up taking a much more flexible approach, as described in our proposal:

“One advantage of iOS and other touch devices is that they support a very wide age range. We hope the game will be playable by children as young as five or six while still being entertaining to adults. Young children will most likely reap the most benefit from the educational concepts the game presents. In addition, we found that we could cater levels to fit different age ranges, making the game customizable for all learning levels.”

While age customization was possible, for the purposes of testing we only had two versions: One for us and college-aged friends, and a simpler version for younger elementary school students. I worked extensively on the kid version, and developed new age-appropriate levels based on regular user testing. Here are a few excerpts from my user testing diary, which was submitted as part of our final project:

4/30/11

The kids had a fun time with a modified version of alect-Digital-Egg-Drop-3357c7c (I added about 30 extra block and nail objects, so they could play longer). They definitely get the nailing aspect of the construction, and used it to protect their egg almost immediately.

++++++++++++++++++++++++++++++++

5/4/11

Tested alect-Digital-Egg-Drop-9f0fc79 on my son. This was the first time he had seen the disasters, which he really enjoyed (especially the earthquake, which sometimes sends blocks flying).

I was also surprised to see that he right away figured out the solution to the wind disaster (nailing something to the floor) which vexed me when I saw it the first time.

He also used extensive experimentation to try to solve all of the problems he observed. For instance, for the earthquake, he tried positioning the blocks close to and further away from the egg, nailing different size blocks to the floor, etc. He gave up after 4-5 unsuccessful tries, at which point I showed him how to do it. Then he played to the end (two tall planks).

He noticed and liked the new egg [artwork].

++++++++++++++++++++++++++++++++

5/6/11

Played build alect-Digital-Egg-Drop-d3eb420, which has some memory issues that Alec addressed. However, we noticed a bug after the second level that prevented us from going to the third level -- the level up button didn't respond on the emulator.

The gameplay is fun, and as a proof of concept it is good, but I wonder if the learning couldn't be more robust. Maybe if we had more time ...

++++++++++++++++++++++++++++++++

5/9/11

Building out levels in XML. I am using Google Docs spreadsheet to track the progressive difficulty of the challenges, and using my own judgement and gameplay to see how they work.

The advantage of using oneself for testing is I can quickly rearrange the blocks or disasters, reinsert them into ResourceManager.mm, and play the new version on the emulator.

I am going to try to introduce it to my son tomorrow morning ... I unfortunately won't see him for the rest of the day.

+++++++++++++++++++++++++++++++++++++++++++++

5/10/11

My son hadn't seen the new designs, so he was very happy to see the artwork. He also liked the meteor, cushion blocks, and the idea of the termites. He got up to speed pretty quickly on the simple progressive levels I set up for him. On the quake level, which requires surrounding the egg with cushions and nailing them together in a certain way, he couldn't solve it, and took an interesting area of experimentation that I hadn't considered -- reinforcing the cushions with wood braces.

The other thing that I am conscious of is the game really has to be customized to age/ability. What appealed to him as a 6-year-old wouldn't appeal to older players.

One thing that’s worth mentioning about the testing is I didn’t need to pressure my kids to help out. Both of them love games. My son has probably tried a few dozen age-appropriate titles on my iPod touch, and regularly returns to the ones that are most entertaining. It was clear that Egg Drop fell into the same league as favorite games such as Angry Birds, Cro-Mag, Fruit Ninja, and the Simpsons game. He simply couldn’t get enough of Egg Drop, even during the early builds when the game was still rough around the edges. Here’s a video of him trying out an early version, about one week into the development process:



Beyond the experience of working on iOS game design, there were several other takeaways from the project. One was being able to participate in a rapid prototyping process integrated with user testing. This combination is held up as an ideal at MIT and elsewhere, but getting the right team and the right testers in place can be difficult. Before coming to MIT, I worked in Web media for years. Even on those rare occasions when my employers had adequate engineering resources in place to develop new products, testing was usually handled in-house and at a very late stage. Sometimes this was because testing was not considered a crucial part of the product development process, but at other times it was difficult to find actual users or the product had to be kept under wraps out of fear of premature leaks or tipping off the competition.

For Egg Drop, not only was the team technologically top-heavy (three out of five were programmers), but we had access to real users in our target audience, which let us observe gameplay, hangups, and other aspects of the user experience. This feedback loop led to better gameplay and helped us eliminate speed bumps and outright bugs at a relatively early stage.

A second takeaway related to gameplay theory. While the Egg Drop project was focused on real gameplay issues and the practicalities of developing a game for a mobile device, I did find myself looking back to some of the research that we had studied in class earlier in the semester, in particular the readings from James Paul Gee. He articulated a lot of modern thinking about models, video games, and learning in his 2008 paper, Learning and Games (e.g., “Video games offer people experiences in a virtual world ... and they use learning, problem solving, and mastery for engagement and pleasure”). His “situated learning matrix” for understanding how context-based learning in games can be applied to the world at large was described in terms of first-person shooters in 3D worlds. But one can see how a modeling experience in a 2D world like Egg Drop (such as my son’s experimentation with reinforcing braces that I observed in the user testing diary) might also be internalized, generalized, and applied to other situations, even if protecting eggs from meteors never figures into his daily life. This ties back to our proposal to "develop the hypothesize -> experiment -> redesign strategy of designing, which is a useful skill in many wider disciplines than construction."

Gee introduced another interesting concept in What Video Games Have to Teach Us About Learning and Literacy. The concept of “Semiotic Domains,” as it applies to video games, basically says that players will find it easier to transition to new scenarios that have similarities to old scenarios they have already encountered. In terms of gameplay, this not only helps explain the continued popularity of RPGs, "shooters," and other genres, but also how specific features work for some gamers and not for others. For instance, my son was already familiar with the iPod touch and physics-based games such as Ragdoll Blaster and Angry Birds, which made it easy for him to get into Egg Drop. However, he was perplexed by the preview of the next object in the upper right corner of the screen. This convention dates from 80s-era games like Tetris, which he had never tried. He therefore applied his own gaming experiences to Egg Drop, and attempted to drag the preview pieces onto the playing area (this can be seen in the video of game testing, above). In a commercial development project, such an observation among many early testers might be a cue to re-evaluate that feature.

A third takeaway from the Egg Drop concerned the design of the game, not only as it relates to gameplay, but also the artwork used in the game. While the cocos2D physics were slick, the graphic elements were very simple (I should know -- I made the bricks and a few other elements using Preview in OS X). But to our young testers, it didn’t matter. The game art was enough to convey the concept, and the gameplay was addictive.

Fourth takeaway: As our instructors mentioned at one point late in the semester, sandbox mode can really work for younger players. I saw proof with my testers on the first few builds, before Alec had integrated the disasters and win states for levels. In the proto-Egg Drop, it was possible to drop a practically unlimited number of horizontal planks around the egg, but there were no disasters or special materials to work with. It didn’t matter. The kids simply liked the physics of the game, which allowed them to fill up the screen and sometimes model strange situations, such as a mountain of planks for the egg to roll down. I have many screenshots from early versions that show the playing area filled with planks:

Now the reality check: The analysis and observations above are based upon an extremely small userbase playing with test versions of the game. The ultimate excitement for Egg Drop would be refining it and releasing it to the wild, to see how a much larger population of players reacts. Of course, “refining it” would involve not only working on some of the issues identified earlier (level design, artwork, etc.) but also considering the original educational vision of the game -- teaching concepts related to construction and physics. We were not able to do enough basic research around how kids might best learn such concepts, which is unfortunate, because I believe the game is a marvelous vehicle for learning. But this also leads to the question of how to balance desired learning outcomes with gameplay. More experimentation would be required.

In the meantime, here’s a video of the gameplay and design, based on the final build in mid-May:



If you are interested in finding out more about the class, take a look at the course website. You may also be interested in reading about another mobile educational game development project I worked on in Linked Data (6.898) last year.

WorldTV - our MIT Media Lab final project

One of the more interesting class projects I took part in during my last semester at MIT was our MIT Media Lab final project for MAS 571 ("Social TV: Creating New Connected Media Experiences"). The project was called WorldTV, and with my team (Jungmoo Park, MBA '11, and Giacomo Summa, MSMS '11), we created a pretty slick video demonstration of the proposed software UI. The video was shown at the MAS 571 demo day at the Media Lab (you can watch it below) and we wrote an accompanying concept paper that we are in the process of preparing for an IEEE CCNC workshop. In the following post, I'll describe not only what WorldTV is, but its genus and some of the reaction we've received so far.

WorldTV is a television app and accompanying mobile app for browsing user-generated video from one's social circle, as well as event video produced by strangers that tie into one's news and cultural interests. Instead of using traditional browsing methods -- scrolling through channels or searching for videos -- the proposed service uses a 3D globe as a navigational tool. WorldTV is aimed at people with global networks, which might include people with friends, relatives, and colleagues from other countries; people who spend a fair amount of time travelling; or people who are interested in news or culture in other countries.

The concept had great appeal to the entire team, not only because of our backgrounds (Giacomo is from Italy, Jungmoo is from Korea, and I spent most of the 1990s living overseas) but also because all of us have observed the exponential growth of user-generated video and realize its power and appeal to ordinary people. In 2006, I wrote about the potential of geotagged, time-stamped online photos to give insights into local events. I expanded the idea to include tweets and user-generated video in a proposal for my Linked Data Ventures class called PPP (PixPeoplePlaces). When I began the Social TV class, I took the PPP concept even further with user-generated video, emphasizing the social aspect of plotting event video on a local map (this was the basis of my first assignment for Social TV -- you can see the poster here).

Developing WorldTV - our MIT Media Lab final project

I envisioned all of these ideas as Web apps displayed on a computer monitor. For one of the early poster sessions for the Social TV class, Giacomo independently came up with a different approach. He asked, why not use a full-sized television screen to display a map of the entire earth with hot spots that reflected breaking hard news events that might be captured by amateur shooters? (This happened as anti-authoritarian demonstrations were breaking out across the Middle East in early 2011). Instead of being a "Lean Forward" experience (something that requires user input or interaction, such as a video game) this would be a "Lean Back" experience, in which the viewer could sit on the couch and take in the video. Giacomo also considered how video could be differentiated on the global map with different sized or colored markers, and how "likes", social networks, or newspaper articles could determine what appeared on the screen. He called it "WorldTV".

There was clearly some overlap between our ideas, and we decided to team up for the final project. We expanded the concept to include not only video from breaking news in other countries, but also cultural events (festivals, parades) and entertainment (sports, performances, etc.). The social filter would not only display streaming/recent videos from one's social circle, but could also reflect the collective interests of the social circle.

WorldTV business model

An additional requirement for the final project was a business model. I had already been thinking about using phone and laptop cameras as a way for ordinary people to access amateur expertise all over the globe, for a price. Examples of amateur expertise might be a power user demonstrating how to use a new gadget, advice on registering a company in a certain state by an experienced business owner, practicing foreign language conversation with a native speaker, etc. I dubbed the scheme Real Time Requests. (RTR). A live auction and reputation system would determine prices paid by people seeking expertise, and match them up with sellers. We decided to fold it into the proposal. The idea was then debuted at another MAS 571 poster session in April:

Jungmoo, who had a background as a professional television reporter for a Korean broadcaster, was intrigued by our poster session presentation and joined the team. Our next task was to take the concept and make a demo to show at demo day at the MIT Media Lab in the last week of class in May. For the final deliverable, we didn't have the skills to produce a working prototype. However, we did have the skills to produce a software mockup and accompanying video demo.

The team got to work. I created a simple WorldTV television UI using HTML and CSS, built the maps with Google Earth, and mocked up a mobile UX on an iPhone "remote". Giacomo wrote the script and starred in the video. Jungmoo took the raw video and graphics and used his professional editing skills to create a really slick video demo, which is shown below:



We presented the video and an accompanying slideshow on the business model last month at the Media Lab. Our Media Lab instructors, Marie-José Montpetit and Henry Holtzman, invited a group of industry pros from major cable and national broadcasters (including NBC and WGBH) to watch all six student presentations. After seeing our team present, one of the NBC visitors was interested in the idea of "shared experiences." Giacomo explained that user-generated video around sporting events and concerts could populate the global view, depending on how one's filters were set up. This prompted another executive, who I believed was from HBO, to question the legality of using amateur concert video. I responded that copyright law was decades behind the technological and social reality, but she was skeptical. I then said that there would always be artists who want to exercise strong control over this content, but there were also many artists who recognized the value of fan content to generate additional interest or loyalty, and in my opinion, the latter group would have a competitive advantage. But as I thought about it later, it was clear that addressing the entertainment industry's copyright concerns would be a huge issue, regardless of how outdated the laws are.

Our team also heard from Henry, who thought the Real Time Requests business model was really a separate concept that did not match WorldTV. We agreed. Jungmoo and Giacomo had actually raised the same concern in our planning discussions, but I felt we needed a business model that did not involve standard subscriptions. Henry noted that a subscription might actually work for some people.

So what's next for WorldTV? All members of the team have graduated, and none of the industry visitors seemed interested in taking it further. We hope, however, that if our paper is accepted to the IEEE CCNC '12 conference, it might get some traction. In the draft that we are now preparing, I outlined the "Future Work" required to make WorldTV a reality:

The next steps for WorldTV would be to create a working prototype using Google Earth, YouTube and Facebook APIs, the Android or iPhone SDKs, and other existing software and hardware components. Besides using the prototype to evaluate functionality and performance, ordinary users in the target audience (people having global networks) could also test the system with an eye toward determining which features and use cases hold the most promise. When the product is ready for wider distribution, identifying suitable “TV App” platforms and partnerships could take place. In the long run, creating a scalable architecture with its own API and opening up WorldTV to outside developers (much like Facebook and Twitter have done) would help unleash the greatest potential of the platform. This would require significant investments, but in the long run would help realize innovations for the next age of television.

If the paper is published, I will share a link on this space. In addition, if anyone is interested in learning more or helping to develop the idea, my contact information can be found here.

A curriculum in computer programming, reviewed

Tweet

You may remember the class exercise for CMS.863J (Computer Games and Simulations for Investigation and Education, taught by Eric Klopfer and Jason Haas) in which our student team created a curriculum for teaching basic computer science concepts and programming skills in World of Warcraft. In late April, an NYU class completed their review of the curriculum and let us know where it was strong, and where it was lacking. Here’s what they had to say:

So our class just finished reviewing several of your curricula to be used within the World of Warcraft environment. We like your concept of teaching computer programming through a process similar to learning gameplay. Your rationale is definitely solid.

You also chose and defined very specific learning objectives. From the perspective of a fellow programmer, these are basic concepts in computer programming that computer science learners would need to know.

Several times in your curriculum, you do a nice job at incorporating built-in functions into the lesson plan, which in turn facilitates better gameplay for the student. This could be a major draw for already experienced WoW players who are looking for ways to improve. What about someone who has less experience/interest in the game?

This brings up a possible limitation with your curriculum: whom do you expect to take your class? You mentioned that young people in general are interested in video games, but it is a specific player that is interested in WoW. Although a learning environment like the one you designed has obvious appeal to those already interested in WoW, those who are not interested in this game might have no motivation to improve their gameplay and therefore learn built-in functions or other commands. It would help if you were more specific when identifying your learner. Then once your learner is defined, do they have the necessary motivation or prior knowledge to complete this curriculum? If not, what kinds of support can you provide to make this learning task intrinsically motivating?

Now from the perspective of an educator, although you have clearly outlined specific learning tasks, your plan on implementing these tasks into a formal learning environment is rather vague. As of now, instructions for your teacher include “ask the students to do…” which is left as is for a lesson plan is not very dynamic. Perhaps you could incorporate actual quests/goals of the game to the lesson objectives. For example, it’s great that you teach certain programming objectives that indirectly teach the player certain built-in functions (e.g. item info, total worth of items in your bag, etc). Wouldn’t it be more motivating if you chose a quest in which knowing what you have in your bag or the price of copper, etc. and being able to pull that information up quickly serves as an obvious advantage in gameplay.

One suggestion is playing on the social aspect of the WoW. It’s unfortunate that the printed scripts only are visible to the individual player. Wouldn’t it be cool if a script your published resulted in actual interchange between players? Or just have another player react to your printed commands? Obviously you are most likely limited by the API or programming language in what a learner can actually change in the WoW environment, but what we want to emphasize is more exercises that result in direct feedback from the printed commands.

After seeing these comments, I totally agree that we missed an opportunity to create a dynamic learning experience with better instructions for teachers and in-world exercises for students. However, regarding the comment about learners who may not have interest in the game, I felt that the boundaries of the assignment were limiting. We were told to create a curriculum around concepts that had to be taught in a classroom environment, using WoW specifically. The fact that some students may have no interest in playing wasn’t something that we had much flexibility to work around, any more than a high school science teacher has flexibility to work around the requirements of using test tubes and Bunsen burners to teach bored students the fundamentals of chemistry. Ideally, a teacher will be able to use the required tools in a way that generates interest and good learning outcomes.

In summary, I think a game like WoW is better than traditional textbooks for engaging students. Besides the fact that almost all college-aged students are familiar with video games, the ability of WoW to allow social interaction, team activities, rewards for better play, and an environment for experimentation makes it a tool that is well-suited for teaching computer programming and other topics. I agree, however, that the curriculum we designed needs better exercises to engage unmotivated students and make the overall learning outcomes better for students and teachers alike.

More blog posts about my MIT experience:

• Infinite Corridor Walthrough
• A curriculum for learning computer programming in WoW
• My MIT center of gravity shifts to digital media
• The challenges of creating a mobile educational app based on Linked Data
• MIT Sloan Fellows program: Soft vs Hard
• Goodbye, Vietnam
• First day of the spring semester ...
• Linked Data revisited: What I learned, what we created, and what's next
• Social TV poster #1: PeoplePixPlaces
• MIT Sloan Fellows: One semester down, two to go

Spark Capital investor on Twitter: "Depending on what day it is, they’re profitable"

On April 13, Todd Dagres of Spark Capital came to speak at our New Enterprises class. Todd is a former instructor of the class, and an established venture capitalist -- his VC bio lists Akamai and a host of investments in other networking companies dating back to the 1990s. He is also one of the much-lauded early investors in Twitter, and after his presentation, he fielded questions from the class. I raised my hand, and popped two questions that I thought were relevant to the discussion about building a profitable enterprise (our assignment that week was a go-to-market strategy for our own business ideas): I asked Todd how the Twitter team sold him on the costs and the revenue potential, and whether or not the company was profitable.

Todd responded:

“The second question I can’t answer. I can say that ... let’s put it this way: Depending on what day it is, they’re profitable. So they’re generating lots of revenue (see, that’s the revenue right there). And depending on how much comes in that day, they can be profitable. So they are monetizing, put it that way.

As far as, did they have a plan? Absolutely. They had a plan that said, 'we're going to grow subscribers, we're going to monetize subscribers.' So they had a plausible plan. By the time we invested, they had decent momentum. They had under ... (trails off)

When we invested, by the way, you’ve got to understand. It’s not like it is now. Back then when we invested, Facebook was a fraction of what it is now. Zuckerberg had yet to be on the cover of a magazine, and Twitter, had, probably when we invested, 600,000 subscribers. Which if you look at it , 600,000 subscribers, that’s a lot. 'Why did you wait until they had 600,000 subscribers?' Back then, it wasn’t as obvious as it is now that you can monetize the subscribers.

When we made the Twitter investment, there were articles in the press that outnumbered the other articles in the press, relative to social networking. And basically what the articles said on the negative side, is 'social networking advertising CPMs suck.' And I even saw one table that said, 'here is the CPM hierarchy.' And down at the bottom, along with the nastiest stuff you can imagine, was social networking advertising CPMs. And the reason given was, 'you have no idea what people care about on social networks. But if they go to a car site, ho ho ho!’

So cars, financial services, things like that had the highest, high tech blogs and magazines and things like that had the highest CPMs, and way down at the bottom was social networking because no one could understand why advertisers would advertise against social networking, ‘you never know what you are going to get.’ Someone talks about what they did last night, 'who cares, who would ever care about that?' But as we know now, Facebook knows a lot about you, and they can target ads against you, better than probably Google can. All of a sudden, social networking CPMs have gone way up, and it’s pretty obvious. ... (trails off)"

I wasn't able to ask a follow-up question, but there are problems with some of the arguments he used to defend Twitter and its revenue potential:

1. Facebook may know a lot about its users, but Twitter does not. Real names and other demographic data are not required for registration. Many people on Twitter deliberately obscure their identities.
2. Facebook CPMs may be higher, but not by much, and surely not approaching the levels that I see Federated Media charging vendors to post display advertising in its network of online publishers (food blogs currently command $5-$12 CPMs, and Business Insider gets >$20 for display advertising). In my own small advertising tests using Facebook's self-serve advertising platforms, I paid for $0.14 CPMs in February 2010 and $0.20 CPMs in April 2011.
3. If it wasn't obvious back in 2006 or 2007 that it was possible to monetize Twitter's subscribers, why invest in the company?
4. Regarding the claim that "depending on how much comes in that day, they can be profitable": Such a defense would never be accepted by the current instructors for New Enterprises (Bill Aulet and Howard Anderson) for our class projects. It's also the sort of thinking that got lots of people in trouble in the late 1990s. Private market trading has valued Twitter at close to $8 billion, not based on real earnings or a plausible business model, but rather the premise that the people behind Twitter will somehow figure out a way to make it work. They haven't so far.

The unsaid argument for investing in Twitter was never mentioned by Todd, and indeed is seldom mentioned in the classes we have on building innovative businesses: A VC's primary responsibility -- or, should I say, fiduciary duty -- is to produce returns for their funds. If the exit is tied to actual revenue or profitability of their portfolio companies, that's great. But if not, who cares, as long as the exit is for a comfortable multiple of the initial investment?

As we have seen many times throughout history with everything from tulip bulbs to dot-coms selling bags of dog food, if enough people think that a popular product or service will be The Next Big Thing, a bevy of dreamers, flippers, and suckers will surely come a-running. Of course, the problem with the sale of unprofitable companies at logic-defying valuations is someone will end up getting burned. While the party is still going, however, no one wants to hear the sour notes. In Twitter's case, its status as a game-changing platform creates value on a different dimension for partners in the ecosystem. But this value does not easily translate to revenue, which once again takes us back to the question of Twitter's long-term value to investors.

More blog posts about my MIT experience:

• Infinite Corridor Walthrough
• A curriculum for learning computer programming in WoW
• My MIT center of gravity shifts to digital media
• The challenges of creating a mobile educational app based on Linked Data
• MIT Sloan Fellows program: Soft vs Hard
• Goodbye, Vietnam
• First day of the spring semester ...
• Linked Data revisited: What I learned, what we created, and what's next
• Social TV poster #1: PeoplePixPlaces
• MIT Sloan Fellows: One semester down, two to go

Infinite Corridor Walkthrough

A curriculum for learning computer programming in WoW

(Updated: See note at bottom of post) What can you learn from the MMORPG World of Warcraft? A lot, it turns out. This is one of my conclusions from taking CMS.863J -- Computer Games and Simulations for Investigation and Education, taught by Eric Klopfer and Jason Haas. It's one of the classes offered this semester by MIT's Comparative Media Studies department, and is also cross-listed under Course 11 (MIT's Urban Studies department). Aside from myself and one other graduate student, all of the other people taking the class undergraduates, many in Course 6.

As indicated by the name of the class, the curriculum centers around computer games and educational theory relating to games and learning. However, like every other media and entrepreneurship-focused class I have taken at MIT, there is also a heavy focus on creating and building (Mens Et Manus is the institute's motto). In February, after getting up to level 13 in World of Warcraft and conducting quests with classmates in-world, we split into teams with the mission of building a sample curriculum around a specific topic area, using WoW as the learning environment.

You may find it strange that a game like WoW can be used to study real-world topics, but there is actually a fairly long history of players using the virtual worlds to study or understand various phenomena. Edward Castronova's oft-cited 2001 paper on virtual world economies opened up a floodgate of research and academic discussion relating to massively multiplayer online games. Specific to World of Warcraft, the game has been used to study epidemiology, as well as topics related to learning. In 2008, a paper by Constance Steinkuehler and Sean Duncan in the Journal of Science Education and Technology studied scientific reasoning in thousands of WoW forum posts. They found that 86% of the posts contained "social knowledge construction," or "the collective development of understanding, often through joint problems solving and argumentation."

As expected, many of these posts consisted of discussions around certain classes of characters, spells, weapons, etc. However, 10% of the total posts studied used model-based reasoning, including mathematical models to explain some phenomenon. An example cited in the paper showed one player who apparently reverse-engineered damage algorithms in WoW to compare the abilities of priests vs. mages:

By intuition, you should notice a problem... but I’ll give you the numbers anyways 

For Mindflay, SW:P, and presumpably VT [3 priest spells]: Damage = (base_spell_damage + modifier * damage_ gear) * darkness * weaving * shadowform * misery 

For Frostbolt [mage spell] Average Damage = (base_spell_damage + (modifier + empowered frost) * damage_gear) * (1 * (1 - critrate - winter's chill - empowered frost) + (1.5 + ice shards) * (critrate + winter’s chill + empowered frost)) * piercing ice mindflay = (426 + 0.45 * dam) * 1.1 * 1.15 * 1.15 * 1.05

650.7 + 0.687 * dam 

frostbolt = (530 + (0.814 + 0.10)*dam) * ((1 - crit - 0.10 - 0.05) + (1.5 + 0.5) * (crit + 0.10 + 0.05)) * 1.06 

(530 + 0.914 * dam) * ((0.85 - crit) + 2 * (crit + 0.15)) * 1.06

0.968 * (dam + 579.7) * (crit + 1.15) 
Please notice the 0.687 versus the 0.968. That's the scaling factor. 

After students in our class had gotten the hang of WoW, there were discussions around how the game could be used to study trigonometry and group psychology. Our team, consisting of Andrew Hsiao and Michele Pratusevich (both course sixers) and myself, opted to use WoW as a platform for high school students to learn basic computer programming concepts, using a simple scripting language called Lua that can be run from within the WoW chatbox. Here's the curriculum that we developed:

Teaching Computer Science Through WoW Scripts

Michele and Andrew were the true domain experts here, and designed all four of the CS class exercises and most of the assessment. I concentrated on the introduction, theory section, and managed to create one of the assessment scripts (the simple currency exchange/variables exercise).

WoW computer programming curriculum review

I personally believe the curriculum we designed is a very effective and engaging method for introducing basic computer science concepts to high school students. Once they've established a WoW player account and learned some of the basic game functionality, it's so easy to experiment with the code, and try new functions from the WoW API. Our instructor said the curricula that the student group developed will be passed to testers at NYU, but I don't know if we'll get any feedback on how our CS curriculum fared. If you are a teacher and try it, or are a solo learner who wants to study basic computer science concepts while playing WoW, please feel free to give it a spin and let me know how it works.

My next assignment for CMS.863J, with a different group: Creating a board game to teach fundamental electrical engineering concepts. You can see our test board here, and I'll try to post more information about the project as development progresses in April.

Update: An NYU class has reviewed our curriculum. Their comments can be seen on the post, "A curriculum for programming, reviewed"

The challenges of creating a mobile educational app based on Linked Data

Earlier this month, my iPod touch flashed a warning message that the provisioning profile on the test application our team (Sloan Fellow Mads, Course 6 undergraduate Yod, and myself) had designed for 6.898 in the fall was about to expire. Before it did, I decided to make a quick video showing the basic design and functionality of our educational app for the iPhone and other iOS devices:

Video: Knowton demonstrated:


While the app was ostensibly designed to teach young children geography facts, the purpose of building it was to show how Linked Data could be used to make an educational application on a mobile device. Mads' original concept was to have an open-ended exploratory app that would let children freely jump from one object to an associated fact. For instance, the child might be interested in a monkey, be able to see a picture and read some information about it, including the facts that it lives in a tree and likes to eat bananas. At that point, the child could either choose to learn about trees or fruit.

This idea is eminently suited to Linked Data, which is essentially a distributed, global-scale database  built around Semantic Web standards such as RDF, turtle/N3 and SPARQL, shared definitions, and links between repositories. There is an enourmous collection of Semantic Web-based data already available, ranging from Wikipedia information to creative commons-licensed photos.

I suggested narrowing the focus to geography, as presenting facts about animals and their habitats could be tied to a specific learning outcome. I also designed a rudimentary user interface and flow (see wireframe  below), which was eventually adopted for the exploration part of the app. Yod designed the basic game flow and built several code repositories, including the mobile app (using the iPhone SDK) and a Web app that let editors (us) submit information such as photos and descriptions. Mads devised a business plan.

In a perfect Semantic Web world, it wouldn't be necessary to have the Web app for editors, as SPARQL queries on consistently structured graphs could build the data store, with only a minimum of cleanup and selection (such as choosing the most suitable photos). But we quickly discovered that DBPedia, a popular source of country-level information for local fauna and landmarks, was incomplete. Freebase filled in many of the information gaps, but there were so many differences from country to country that the only practical way to tackle the task of preparing the data for the mobile app was by using the Web interface that Yod created. For geography and many animal photos, we used a source that one of the guest lecturers in class had mentioned, Ookaboo, which contained creative commons and public domain photos. Others were sourced from Flickrwrapper using a feature in Yod's Web application.

But for good "people" photos that could not be easily accessed in Flickrwrapper using basic search strings, I had to resort to finding creative commons-licensed (CC-SA) on Flickr itself and copy and paste URLs into the Web app. Even if we had been able to use Linked Data without the manual workarounds, there is no way we would have been able to run live queries from the mobile app -- not only are mobile network connections unreliable, but we discovered that many of the sites have high latency and/or frequent downtime (DBPedia especially!). As an alternative, Yod built a database that loaded onto the app and was instantly accessible by users.

On demo day on December 7, all of the 6.898 teams gathered in a CSAIL conference room at the Stata Center. Tim Berners-Lee and a group of outside judges watched our demos and listened to our business pitches. TBL's quick assessment of the projects is in the video at the bottom of this post, but we approached him afterwards to ask him about the curation problem. He suggested some AI alternatives. For instance, if Linked Data sources identified "China" as alternately being a country or a person, he said the app could choose the most suitable definition based on the number of returned sites in competing Google searches.

TBL asked about photos in Flickrwrapper. Could Flickr ratings be used to choose better-quality photos? Yod said no. TBL suggested that some geocoded logic could be used to get the best Big Ben photo. "Make sure it's 300 meters west at a certain time during the day," he said, and then joked: "But how can you be sure that it's not a photo with Aunt Jenny in the frame?" He speculated that an algorithm could help choose photos based on contrast or some other value.

Video: Tim Berners-Lee reviews the 6.898/Linked Data Ventures class projects (Knowton comments at 2:50)



Other posts about my MIT Sloan Fellows experience:

• My MIT center of gravity shifts to digital media
• MIT Sloan Fellows program: Soft vs Hard
• Goodbye, Vietnam
• First day of the spring semester ...
• Linked Data revisited: What I learned, what we created, and what's next
• Social TV poster #1: PeoplePixPlaces
• MIT Sloan Fellows: One semester down, two to go