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.
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.
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.
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. More posts and videos relating to my MIT experience are listed below:
