This game focuses on teaching balance to the player, as they must plant flowers to counter balance the different bugs on the plank. The design is based heavily on a research paper done by Carnegie Mellon University professor Robert Siegler on balance experiments.
PLAY it at: beanstalk.etc.cmu.edu!
The goal of this game was to introduce balancing mechanics beyond that of the standard "teeter-totter" playground equipment. Beanstalk introduces 4 slots on each side of the beam instead of one, and children get to discover that balancing isn't as simple as they might have thought.
Just like all games under the ENGAGE initiative, the long-term goal is get more kids interested in science and engineering careers.
Our mission is to help children better understand balancing and to see if they are learning from the game.
This game is the second in a multi-mini-game project, which is part of ENGAGE. The first game, RumbleBlocks, kicked-off the project and helped us learn what was and what wasn't helpful in building educational kids games. Some examples would be how kids handle a mouse and keyboard, their familiarity with a computer and handheld devices, and the importance of a narrative.
Our goal is to build an educational game that "hides" the educational objectives behind fun mechanics. We then collect data about how the beam is balanced and the inquiry and socio-emotional learning answers through a logging server to determine if kids are learning from the game.
Our audience is Pre-K through 5th grade, with our core audience being 1st and 2nd graders. Knowing that we have such a wide range of ages and early grade levels, we needed to build the game knowing that a good portion of players would not be able to read. We also discovered that younger kids have a more difficult time using more complicated control inputs. So we went with just mouse inputs.
The hardest challenges are the ones that don't have clear answers. With these games, one of our objectives is to implement SEL (Socio-Emotional Learning); in otherwords, the processes through which children and adults acquire and effectively apply the knowledge, attitudes and skills necessary to understand and manage emotions, set and achieve positive goals, feel and show empathy for others, establish and maintain positive relationships, and make responsible decisions. The ideal method is to have 2 or more kids playing the same game (whether taking turns, co-operative multiplay, or some form of versus) and have them learn and understand and begin to apply SEL skills in the real world. An simplified example of this is you're picking apples, but the bag is too heavy to carry by yourself. Do you ask for help (A), or (B) empty some of the bag and carry it yourself. Throughout the games we've made, they've all been an interaction with an AI player, which works to some extent; but an AI has a pre-determined outcome and reactions, whereas kids are completely unpredictable.
We've designed and touched base on a few multiplay ideas for SEL, but we think that the best method to tackle this unanswered objective is to build a few game prototypes specifically for SEL gameplay, instead of making it a side addition. We say this because the amount of time in a given semester is too short to implement a complex system for network gameplay amid other design and programming obstacles. There's also a number of other obstacles that would have to be designed and researched, because due to our age group, voice-chat, reading and game lobbies are something we would like to avoid.
Unlike most educational games, we are focusing on not just one learning topic, but a few that are all connected to each other. RumbleBlocks, Beanstalk and Helios are all interconnected with their teaching principles grounded around physics - aimed at very young ages. The core physics principle, if we had to boil it down to one word, would be stability; balancing a beam, constructing stable towers.
We are also attempting to break new ground with SEL implementation (Socio-Emotional Learning). RumbleBlocks touched on a few designs ideas and played around with the concept, but it didn't fully come into prototype and testing phases until Beanstalk.
With these games, we are also trying to inspire more people at very young ages to pursue science and engineering careers through the use of fun and entertaining educational games.
Anyone can help! We need lots of playtesters, critiquers, teachers, etc. Know someone that fits into our audience? Even better, have them try the game and send us some feedback! Found a bug? Something doesn't look right? Maybe we missed something. The more feedback, the better our product.
Our original team was comprised of a total of 8 people: Danny Hausmann, Sean Brice, Matt Champer, John Balash, Nora Bastida, Chandana Bhargava, Weiwei Huo and Xun Zhang; with advisor support from Scott Stevens and Mike Christel, while Bryan Maher built the logging platform.
The game was later updated and improved upon additionally by Samantha Collier, Cathy Chase and Erik Harpstead.
We initially designed a prototype, simply titled "Ramps" in which you had to get a spherical character to conceptually "Rube-Goldberg" their way down a series of ramps in which you needed to select the ramp height. This prototype was built quickly and didn't last long due to discovering the other half of the ENGAGE project was working with a similar mechanic and we did not want to invade their intellectual space.
We then design a 2nd prototype in which you had to grow a beanstalk and the core concept was about growing vines and branches off of it with varying lengths and materials. Part of the team designed a 3rd prototype towards the end of the semester which was based on balancing a beam at the tip of the beanstalk. The third prototype ultimately gained ground due to it's educational research backing with Robert Seigler's Three Aspects of Cognitive Development research study. We playtested both to see which would win the focus of the full team and went with prototype 3. This ultimately set the goals for the next two projects which built Teeter-Totter Go! and Helios.
We changed the tutorial a few times because playtesters weren't noticing certain things. So instead of having the whole game at full zoom, we would zoom in on a focused area until they clicked what we wanted them to do. It would seem obvious that if a pointer is pointing to something, you would click it; but like the Microsoft Office Paperclip, no one pays any attention to it. Tutorials can't be on rails because the point of a game is to explore and discover things on your own. Tutorials, if even needed at all, need to be folded into the experience and narrative as much as possible.
The initial concept and design for Beanstalk was far different than the final outcome:
It was designed with a very stylized setting where the earth was sort of made very small so that it contrasted well with the gigantic beanstalk. Jack was supposed to be the socio-emotional aspect where he interacted with the player. The whole game was built around the idea of Center of Mass, which was what HCII wanted to focus on since RumbleBlocks didn't get a very good look at it.
The game would have played with the beanstalk continuously growing (unless you paused the game) and it would constantly grow towards the Sun. The Sun was on an arc that moved back and forth with the mouse. If the center of mass dot went too far outside the area it should be kept in, the beanstalk would have too much top-weight and topple to the earth far below.
Our first Beanstalk prototype involved growing a a main vine and selecting which attributes and growing it out in an exploratory way. We initially considered making it paused while building until you hit the play button (step 5), which went with the story book theme we were going for. We eventually removed this because we found it's better for kids to react in real-time.
The way this prototype played out was you would first select the branch sprout (1) that you'd like to grow, then select a length (2), which also was weight. You then would select the width of the branch (3) - thin, normal or thick; and lastly (4), an attribute - spiky or gooey. Goo let you stick to the branch like a bug when there was high winds, and spikey could bust through storm clouds.
In order to make sure our audience is adapting and using our product, we need to (and are in the process of) launch our game on various kids and learning sites across the web so that we can get a lot of crowd sourcing and data mine the game.
We are currently working to get Beanstalk onto multiple educational websites and portals to increase our player population. We are currently in the process of getting it onto Learning.com and CS2N.org.
Repetitive tasks dilute the experience and will not keep a child's attention, therefore making it harder for learning retention. Too many things for a child to think about will pollute the space and the learning gains. The balancing space is too narrow to make a robust game that looks into all three areas: core gameplay mechanic of balancing, inquiry and SEL implementation. We learned from this and applied it to what would become Teeter-Totter Go!, then eventually Helios, where we feel we have finally found a good balance of the three by creating a new narrative that helped the three spaces. We also took a brand new approach to the level design and inquiry/SEL design so that it didn't feel repetitive.
The successes were our playtests and playtesters. We could not have done it without them. Early and iterative playtests are the key to shaping any game, and without them, we would have been lost down the wrong road a long time ago.
We drew a contrast with Beanstalk and let the players choose their gender, and they liked this feature quite a bit, enough that there was some excitement and audible exclamations at some of the playtests. Since this point forward, we've included gender selection in all of our games.
The tutorial was a bigger challenge than we thought it would be. It was iterated and changed a few times due to playtesting results. But we learned from it, and when we created Helios, we integrated instruction with the player helping another character and the narative. We pretty much got the tutorial right on the first attempt.
Another challenge we had was that repetitive gameplay leads to learning and attention loss. We patched this up with changing how level progression works and how many levels you had to play / get correct before playing a SEL/Inquiry level.
We learned that gender selection was pretty important for young audiences. In the case of RumbleBlocks, it didn't matter too much because we intentionally left the gender area vague for sake of simplicity.
We also learned repetitive gameplay leads to loss of the player's attention and learning gains. In addition to this, we have a SEL implementation where two birds ("Crow and Chicken") talk to the player about balancing mechanics with big science words. The core problem was not the dialogue or the word useage, but more that the game itself was unbalanced. The SEL/inquiry implementation on average was almost double the length of a gameplay level, or several gameplay levels. We've since tuned and turned this down, but sometimes it's just better to start from scratch - which is what we did with Teeter-Totter Go! and Helios.
Beanstalk is available to download and explore in order to see our work and how it was done. You can download it from the Carnegie Mellon University Entertainment Technology Center (ETC) DARPA ENGAGE page and you can read about its development from this Beanstalk conference paper.
For teachers, educators and the like, we've made the art assets available as "ClipArt" to use in whatever creative way you can come up with. Powerpoint slides, Word docs, or even print them out and use them on paper! They are available in the PNG format so as to provide transparency (no white borders). They can be found here: http://www.etc.cmu.edu/engage/files/BeanstalkClipArt.zip
Learning from our mistakes and what makes a better game - and experience, was taken primarily from the RumbleBlocks effort and put forward to Helios, Beanstalk and Teeter-Totter Go! While Beanstalk ultimately had several different versions and prototypes before it was built, they all incorporated a narrative and a character to some regard. At the moment, we think RumbleBlocks has hit an ending point in it's evolutionary stage; but that doesn't mean that it will cease to get small updates and improvements as we launch it around the web and tweak it for maximum fun and educational effectiveness.