The games we played as children: Relievio

It's now early September. Hearing the crickets at dusk takes me back to the warm late summer evenings of yesteryear, and the sounds of neighborhood kids playing outside. 

Growing up, what were the games you played with your neighbors or siblings? Hopscotch? Stickball? Jumprope? A list of children's games is endless. But I wanted to mention a special one: Relievio. 

From age around the age of 8 to 12, this was a favorite game in our neighborhood. Relievio was a simple game, a cross between hide and seek and capture the flag, but spanned all of the properties on the street, including back yards. You needed at least a half-dozen kids to play, who were divided into teams. There was also a "jail," but the captured kids could be freed by a teammate. There were special phrases and calls, including "Ollie Ollie in come free." 

We would play after school until it got dark or it was time for dinner. On a warm night, we would go home for supper, but then come out again to play until twilight or our parents called us in. The cries of the game and shouts of glee when someone was tagged echoed throughout the neighborhood and then faded as everyone drifted home. As darkness fell, the crickets started their own calls. The block fell silent until the next day. 

I always assumed that one of our cleverer or more social friends made up Relievio, or perhaps learned of it from other kids in our town. Recently I learned that Relievio actually has a long tradition, going back to the 1800s and spreading across at least two continents under various names. The origins are obscure, but it seems to have come from Britain. The game-ending phrase that I heard as a child - "Ollie Ollie In Come Free" - was likely "All ye, all ye, in come free" at some point. We had no idea! 

Nicole grew up on the other side of the world and never heard of Relievio. But growing up, she and her siblings and friends had their own games and traditions. Every group of children did, no matter where they lived, or when they lived, as this Breughel painting shows:

Remembering these games now brings a smile to our faces!

As for our own children, our teenage son never heard of Relievio. It's sad, but it's not the first gaming tradition to fade away. I remembering hearing about kick the can, and would find scuffed marbles in the school playground, but never played these games myself - they were the domain of an older generation of children.

But other games live on. Our son played some of the same games that we did 40 or 50 years ago, including touch football and run the bases. In the winter, he went sledding with his friends. Both of our kids were enthusiastic Halloween participants through middle school. These and other childhood traditions will live on ... or perhaps be replaced by something new.

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.

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

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"

An academic gets a rise from "breaching experiments" in City of Heroes/City of Villains

(Update at bottom) This is interesting. A university professor has released a sociology study (which will soon be made into a book) using players in the MMORPG City of Heroes/City of Villains as research subjects (see video at the bottom of this article which shows gameplay). I saw it discussed on Hacker News, and read the article on nola.com that prompted the debate. After reading the 2008 research paper ("Play and Punishment: The sad and curious case of Twixt") I thought that I would give some analysis here on my blog, and add some of my own thoughts regarding academic ethics.

From a high-level examination, the study seems harmless. In it, Loyola professor David Myers exploited differences between the online game's official rules (mostly governing gameplay and competition) and unofficial rules (mostly player-created social norms) to study group behavior. Starting in late 2006, he used his player to build specific scenarios and observed the reactions of other participants.

But drilling down to his methodology, the study veers into uncomfortable territory. Myers didn't just play the game, he actually used his hero character "Twixt" to sabotage other people's enjoyment by violating the game's unofficial social norms. In other words, he took the role of an antisocial griefer to an extreme in order to drive social and emotional reactions, which he then used to support his thesis.

Here's how Myers describes his methodology:

These three sets of behaviors – rigidly competitive pvp tactics (e. g., droning), steadfastly uncooperative social play outside the game context (e. g., refusing to cooperate with zone farmers), and steadfastly uncooperative social play within the game context (e. g., playing solo and refusing team invitations) – marked Twixt’s play from the play of all others within RV.

Translation: He killed other players in situations that were allowed by the game's creators but frowned upon by the majority of real-life participants. For instance, "villains" and "heroes" aren't supposed to fraternize, but they do anyway. When "Twixt" happened upon these and other situations -- such as players building points by taking on easy missions against computer-generated enemies -- he would ruin them, often by "teleporting" players into unwinnable killzones. The other players would either die or have their social relations disrupted. Further, "Twixt" would rub it in by posting messages like:

"Yay, heroes. Go good team. Vills lose again."

The reaction was overwhelmingly negative. People used message boards and in-game chat to tell Twixt how much he was hated, what a terrible player he was, and worse. While Myers was technically following the rules of permitted gameplay, he was violating the rules of conduct to such a degree that even heroes were begging for villains to kill Twixt in the game.

There were also some extremely disturbing reactions to the experiment. Myers received at least one threat to kill him in real life, although it's not certain if the player who said this was being serious, as Myers' real identity was not known to other players at the time. This video interview with Myers discusses the incident:

Computer Game Threat

All in the name of science, right? Anyway, here is how Myers' summed up the implications of his experiments:

In real-world environments, "natural" laws governing social relationships, if they exist at all, are part of the same social system in which they operate and, for that reason, are difficult to isolate, measure, and confirm. In Twixt’s case, however, two unique sets of rules – one governing the game system, one governing the game society -- offered an opportunity to observe how social rules adapt to system rules (or, more speculatively, how social laws might reproduce natural laws.) And, the clearest answer, based on Twixt’s experience, is that they don’t. Rather, if game rules pose some threat to social order, these rules are simply ignored. And further, if some player -- like Twixt -- decides to explore those rules fully, then that player is shunned, silenced, and, if at all possible, expelled.

I had a couple of additional thoughts about Myers' study. When I was in grad school, we devoted some time during the required proseminar to academic ethics. As I recall, experiments in which subjects were not made aware they were taking part in an experiment were to be treated very cautiously. The example that was brought up in class was a 60s-era study that involved a researcher monitoring the activities of men having sex in a public restroom that was known as a pickup spot for anonymous rendezvous. Such a study could not happen now without raising red flags, owing to privacy and consent issues. While Myers' research did not infringe upon players' intimate lives, he apparently did not get their consent and he did not reveal that he was an academic conducting research.

There is also the emotional element to consider. He was manipulating people's feelings for the sake of an experiment. That seems questionable, despite the suggestion in the nola.com article that he was surprised people reacted the way they did.

I believe Myers anticipated he would draw an overwhelmingly negative emotional reaction before he even started his "breaching experiments." It's not just that people hate to lose. Myers has studied video games since the 1980s, and played City of Heroes/City of Villains for thousands of hours before he started his research. Surely he knew that killing other players in such a fashion went beyond griefing -- these virtual characters are representations of the people who play them, and the advanced characters have taken huge chunks of personal time to build. The article on nola.com notes that "Myers was stunned by the reaction, since he obeyed the game's rules." This seems a bit hollow. After all, he acknowledged that his methodology employed "steadfastly uncooperative" tactics -- what was he expecting, a medal? The social rules may not be explicit as the official game rules, but he must have expected negative consequences for violating them in such a manner, just as employing uncooperative behavior in a real-world situation would prompt negative or even angry reactions from others.

Update 7/7/2009: I found Professor Myers' blog, and a post in which he addresses the academic ethics involved in his research. First, he suggests that this is not technically an "experiment":

... this study is not really an experiment. I label it as a “breaching experiment” in reference to analogous methods of Garfinkel, but, in fact, neither his nor my methods are experimental in any truly scientific sense. This should be obvious in that experimental methods require some sort of control group and there was none in this case. Likewise, experimental methods are characterized by the manipulation of a treatment variable and, likewise, there was none in this case.

He goes on to claim that the lack of consent from the people in his research does not constitute an ethical breach:

The matter of informed consent in this case, because of the reasons above, is really more of a legal than an ethical issue. You will note that I reveal no real-life identities. Nor do I use player globals. The names of toons I do include in the paper are entirely immaterial to the paper’s content and could easily be changed – which I am quite willing to do, though I think it will make little practical difference to the players involved. Most of them, I think, would rather have the names in rather than out. None of them, after all, despite the claims of some, were “treated” or “manipulated” or “harmed” in any way. They were simply observed in how they played within the zone, similar, perhaps, to observing how people shop inside a shopping mall.

This is a false comparison. The players were not "simply observed," they were subjected to what he calls "steadfastly uncooperative" behavior. If he were to employ corresponding behaviors in a shopping mall, the result would almost certainly be verbal abuse from mall patrons and ejection from the property for harassment.

Finally, he refers to a Terra Nova discussion on informed consent, which is a great read. However, he did not follow the same rules of engagement as Terra Nova author Constance Steinkuehler, who says:

My general MO to date has been to keep the lines between my professional identity and my Lineage identity transparent to whoever is interested, treating in-game disclosure of information about my 'academic' life the same way I treat academic disclosure of details about my 'game' life, based on the notion that I am bound to both communities to be generally forthright about what I do.

Feel free to add your thoughts below about these issues.

A video of the gameplay in City of Heroes/City of Villains:

The open-ended first-person shooter: A template for 21st century storytelling?

I've been playing videogames since the 1970s. I didn't try out a first-person shooter until 1996, when I happened upon a copy of Doom on a used ThinkPad I purchased in a Hong Kong computer bazaar. The 3D environments, the challenges, the puzzles, and the action were addictive, and I was hooked. Since then, I've played about a dozen or more FPS titles on various hardware platforms. My favorites: Return to Castle Wolfenstein (for the Mac) and Half Life 2 (for the original Xbox).

That is, they were my favorites until I tried Fallout 3 for the Xbox 360, created by Bethesda (see interview below, which includes some clips of gameplay -- note that it is extremely violent, and not suitable for children or the sqeamish). This FPS is similar to the titles mentioned above in that users play a character that has to use wits, exploration, and shooting skills to win the game. However, there are two additional elements that really set it apart:

• Characters become good or evil depending on their actions in the game
• The 3D environment is an open world instead of a fixed channel

While I'd heard of other games that had different outcomes depending on how you played the game or whether you were nice or mean, and had seen how cooperative/antagonistic behavior impacted massively multiplayer online games like World of Warcraft, Fallout 3 was the first such FPS with this feature that I had a chance to play.

It was intriguing to see how non-player characters (computer-generated "people", animals, and robots) interacted with or reacted to my character, based on how he behaved. It totally changed the gameplay -- in some instances, getting "bad karma" resulted in being attacked and killed, or potentially losing the assistance of certain NPCs.

For example, an NPC named Paladin Cross came to my aid at one point and basically helped me survive several major combat situations. But, because she is associated with an honorable group that is out to save the world, the paladin is programmed to leave if the player steals from or hurts allied or innocent people. In other words, being bad in her proximity makes the game more difficult.

In other instances, being nice to strangers opened up new missions within the game (usually to deliver something, find an object in a difficult place, or locate someone.) I generally tried to play "nice" throughout the game, and gathered mostly good karma, but I wondered what would happen if I was bad throughout.

The second major change was the world of Fallout 3 – the "Capital Wasteland" around a post-apocalyptic Washington D.C., was an open-ended world. This is not typical of the FPS titles I've played in the past, where the player is channeled through specific locations in order to advance to the next level, and exploration is limited to that channel. In Fallout 3, buildings, subways, and cave systems usually have fixed channels that control the player's path, but outside it's possible to wander anywhere in the world (kind of like an MMOG), have random interactions with the beings encountered there, and enter buildings and do missions out of order. This adds a random, almost serendipity feel to the game, and is great for "explorer" personalities like me (see Richard Bartle's list of virtual world player taxonomy).

Along with the good/evil element described earlier, the open-ended nature of the game guarantees that no two games will be exactly alike. This is different than the models established by Doom, Half Life 2, and the popular WWII FPS titles I've played in the past, in which there is only one real path to take, and only one outcome to the game (or two, if you include the death of your character). In Fallout 3, the player is given a plot framework and has a lot of leeway to take the story in new directions.

This aspect of Fallout 3 -– along with the beautiful environment created by Bethesda's artists and various unexpected twists and characters -– made me wonder if these types of open-ended games are the template for 21st-century storytelling. I've alluded to the possibility of user-customized machinima in earlier writings (see Video, Computer-Generated Environments and the Future of the Web and "Meeting the Second Wave: How Technology, Demographics, and Usage Trends Will Drive the Next Generation of Media Evolution") but Fallout 3 involved active play within the story world, instead of passive consumption of a customized, linear plot.

The immersive experience of moving about this desolate, beautiful 3D world (unbelievably gorgeous and detailed in HD), and interacting with a wide range of characters, creatures, and subplots reminded me of some of the rich fantasy worlds created by storytellers such as Ridley Scott's team (Blade Runner) and Gene Wolfe (The Book of the New Sun). Of course, those stories centered around violent, loner characters on a futuristic mission. This dovetails with the FPS genre, but other types of stories – romance, comedy, drama – may find their 21st century voice in customizable machinima.

Video interview with Fallout 3 designers (Note: Very graphic violence depicted in some gameplay clips. If you cringed watching the introductory scene in "Saving Private Ryan," don't watch this):

Xbox vs. Wii: Guess who strikes out?

I tried to like the Wii. I really, really tried.

Wii was great for some things -- playing Wii fishing with the kids, or setting up Wii tennis and Wii boxing matches when friends came over. But for serious gaming, the Wii simply hasn't been able to compare to the Xbox, the Xbox 360, or PC games.

There are two things that are holding the Wii back. Ironically, one of them is the thing that makes it so special -- the motion-controlled apparatus which allows users to employ gestures and arm movements to complete actions on the screen. While the Wiimote/Nunchuck pairing is great for games that depend on a single repetitive action -- swinging a racket or bowling a ball -- it stumbles for more complex games. For Wii's Legend of Zelda, the storyline and characters were interesting, but every level came with a new set of motions to learn. Some tasks required very precise movements and button combinations which proved frustrating. After a certain point, it became a headache. I didn't want to go on.

The second thing that is holding back the Wii is graphics. I am not someone who gets worked up about GPU specs and ray tracing minutiae, but the Wii is ridiculous. Forget about comparing it to the Xbox 360 -- I don't thing the Wii comes close to the original Xbox. For the simple games in Wii Sports and Wii Play, graphics not a major issue. But for immersive environments that are typical for MMOG games and first person shooters, Wii's cartoon world won't cut it. I've been playing FPS titles since Doom I, and can't imagine the Wii doing justice to something like Return to Castle Wolfenstein or Half Life 2.

So, even though we've had a Wii in our house for about 9 months, I don't think wii'll (Geddit?) be using it much in the future, except when the kids are exceptionally bored. For the games that I like, I'll instead be using an Xbox 360, or playing PC games that my old iMac can handle. So far, I've only tried one Xbox 360 title -- Fallout 3 -- but have been very impressed. Microsoft gets lots of grief for Windows, but I have to say that the Xbox team really put together an impressive gaming platform. That's where I'll be for the foreseeable future ...

Image: Nintendo

Nintendo: Yes, we know about the Wii shortages

This afternoon, I was able to get a quote from a Nintendo official about the continued Wii shortages.

You'd figure that after the widespread shortages of the console in the 2006 and 2007 holiday shopping season, Nintendo would flood the market with Wiis. Not so. While production has increased, it's still very apparent that demand is outstripping supply. Wii hoarding is also quite apparent, judging by Amazon.com's Wii purchase policy and the $100 markups by Amazon's partner companies.

I wrote about the shortages last year, after I attempted to get one for my own family:

"So you want to buy a Wii this holiday shopping season? Good luck!"

I wasn't able to get one last Christmas, but a friend got one for me in the spring of this year after spotting them on sale at the local Walmart. Interestingly, the biggest fans aren't my kids -- they're my thirty-something friends. One evening over the summer I had four of them playing Wii Sports and Wii Play until after midnight ... I practically had to kick them out of the house!