This game is designed to teach children ages 4-11 how to build and identify stable structures. In the game, players must build towers by manipulating a series of blocks in order to help a friendly alien creature get to its spaceship so it can return to home.
PLAY it at: rumbleblocks.etc.cmu.edu!
The goal of this game was to introduce principles of stability at a young age (4-11) and to collect relevant data on whether children are learning from it. 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 principles of a stable structure.
This game is the first in a multi-mini-game project, which is part of ENGAGE. By building this game, we learned what was, and wasn't, helpful in building an educational game for kids. 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 towers are built 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, with the occassional use of the space-bar to rotate an object.
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. A simplified example of this is you're picking apples, but the bag is too heavy to carry by yourself. Do you (A) ask for help, 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 5 people: Luke Jayapalan, Qiaosi Chen, Jing Jin, Sean Brice and Matt Champer; 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, Xun Zhang, Nora Bastida, Danny Hausmann, Cathy Chase Derek Lomas and Erik Harpstead.
Our main process for building and designing the game was kick-started by the idea of using physics in some regard. Eventually we chose Unity for it's multi-platform delivery methods and ease of use, along with it's physics capabilities. We then iterated and designed a few ideas, which were pitched to HCII and we ended up with a block building game. It wasn't the alien and the spaceship at first though; it was just a bunch of blocks with a star at the top - rather boring and no narrative.
This process of iteration and pitching ideas back and forth continued throughout the development process and some creative new additions were made because of this. Some of the examples include the various mini-games such as the Block Removal levels (e.g., Jenga), Tower Selection (which tower will stand after an earthquake) and the lenses function which shows varying attributes of each tower.
We've self-discovered that games are inherently better and more interesting when they have a narrative, and even better if they have a character. Even if it's very minimal. Some could argue that you don't need either (e.g., Tetris), but they're aren't that many games that exclude both, and generally, these games only hold a short amount of an attention span - we need a longer one, and one that creates an urge to make players come back for more.
Some of our initial level designs included buttresses and supports, force fields/barriers, collaborative building (2 player), building whacky structures to get to a star, filling in shapes, weighted blocks and bridges. We even designed a teeter-totter style game before Beanstalk's prototype was designed!
Here are some of the examples:
An early ramps design where you puzzle-piece blocks together to build a ramp:
Another early design where pirates overboard tried to crowd a beam out at sea and you had to select where they needed to go to balance it out to save more pirates:
An early level design - they got incredibly crazy:
A collaborative design, players took turns placing blocks of their color:
Scaffolded Structures; the green blocks were pre-placed and players had to build around them with a set inventory:
A tower built with putting heavier objects on the bottom (early low center of mass concept):
Building around obstacles and cliffs:
Using Struts to build a bridge:
Using a silhouette to guide tower construction:
Just like our design stage, our prototype stage underwent a lot of iterations and changes, mainly due to a lot of helpful feedback.
Our earliest prototype was just a few simple shapes in Unity and we tested out which shapes were more ideal and which weren't so much (this is where anything circular got cut).
Our second prototype was then built with more shapes, some improvements to the inventory system, but nothing had a very clear design direction. The shapes weren't built with a grid system, the lengths and widths were arbitrary, and we still didn't have a visual style set.
We took feedback, made more improvements and iterations and came out with our first prototype that actually had something of a win state. In this version, the player has to place a "star black" at the top of the tower and the tower lit up, as well as lighting up the background and shooting off particles. Where this had some positive reaction, it wasn't quite enough to keep players engaged and interested.
We then updated the art style, and eventually included the narrative with the alien and the spaceship. An example of what the art looked like before it got the final pass to make it look more "painterly" in our final build can be seen below. This is also where the triangles got cut because it was found they weren't useful and just cluttered the inventory.
At one point, our first mini-game that involved picking which tower was more stable before an earthquake hit, looked a bit like this. Just solid towers. We call these levels "contrasting cases"
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 RumbleBlocks 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.
Kids love stories. They give purpose and a goal and it makes them feel like they are being helpful. Kids also love settings and environments, and everyone will have their favorite, which is why we included not just an earth backdrop, but several different ones to keep things interesting.
Also, sandbox gameplay adds to the experience and gives the game replay value; which is driving a lot of design in today's games. Add to this the fast pace with the inclusion of the earthquake and there's enough tension to keep things interesting and moving forward.
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.
Since this was built at a graduate school with graduate students working on it; this was subject to a grade. The faculty was a bit skeptical (as they should be) that the game was fun and that children were learning. And while we didn't have a lot of concrete evidence at the close of the first semester with RumbleBlocks and learning gains, HCII did come back a few months later and proved there was some learning gains. All it took to remove the faculty's skepticism on the fun aspect was to show them the kids actually did have fun playing the game. And they did. We even had a few playtesters that went to one of the first RumbleBlocks playtests and asked if he could play it again - a year later!
Our biggest challenge was making sure that our game was justified in teaching such a tactile activity. Our biggest argument was "why can't they just play with real blocks?" The answer is that gameplay mechanisms offer features real world activities can't replicate: data logging, narrative, scaffolding (energy balls that light up) and mass distribution. With these mechanisms, we can learn whether kids are learning from our game, guide them to build certain types of towers while still giving them freedom to build as they wish, and keep the tension and excitement high with a narrative.
Incorporated a narrative earlier. Anything - because without it, the playtesters were bored and didn't bother to give us much meaningful feedback because they were distracted by what was obviously missing.
Eliminate more than one input from the mouse - right and left click ought to be the same function (web browsers make this a little more difficult to control). Also, a better input for the rotation of blocks - spacebar works, but it's not completely perfect. There is nothing difficult about rotating, but for a game that tries to be so simple, this is the most advanced feature.
RumbleBlocks is available to download and explore in order to see our work and how it was done. You can download it here: (links coming soon).
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/RumbleBlocksClipArt.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.