You can play RumbleBlocks at RumbleBlocks website!
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 home.
The goal of RumbleBlocks, our first 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 to get more kids interested in science and engineering careers.
This game is the first in a multi-mini-game project. By building this game, we learned foundational knowledge what was, and wasn't, helpful in building an educational game for kids. Some examples include how kids handle a mouse and keyboard, their familiarity with a computer and handheld devices, and the importance of a narrative.
Our goal was to build an educational game that "hides" the educational objectives behind fun mechanics. We then collect data through a logging server about how the towers are built, including retries, number of moves, how long they play a level, etc. in order to determine if they are learning from the game.
Our core audience is 1st and 2nd grade, with an applicable range of Pre-K through 5th Grade. 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 occasional use of a 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. 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 of 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.
RumbleBlocks compared to other Educational Games
Unlike most educational games, we are focusing on not just one learning topic, but a few that are all connected to each other. RumbleBlocks, and it's sibling games Beanstalk, Teeter-Totter Go, Helios and PuppyBot Rescue 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 design 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.
The Evolution of our Project
Our main process for building and designing the game was kickstarted 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 several ideas, which were pitched to our partner, the HCII (Human Computer Interaction Institute) 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.
Some Interesting Insights
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 it 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 spand - we need a longer one, and one that creates an urgency to make players keep playing and come back for more.
Our Initial Concepts
Some of our initial level designs included buttresses and supports, force fields/barriers, collaborative building (2 players), 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
An early level design - they got incredibly crazy
A collaborative design, players took turns placing blocks of their color
A tower built with putting heavier objects on the bottom (early low center of mass concept)
Using Struts to build a bridge
Evolution of our Prototype
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):
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.
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
The idea of the design was to build a tower in the direction of the green paths (not present in-game) and hit the atom-like looking checkpoints along the way to reach the star
Scaffolded Structures; the green blocks were pre-placed and players had to build around them with a set inventory
Building around obstacles and cliffs
Using a silhouette to guide tower construction
We then updated the art style, and eventually included the narrative with the alien and the spaceship. here's an example of what the art looked like before it got the final pass to make it look more "painterly" in our final build. 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":
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.
Our successes came from 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!
A look back on Challenges
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 not replicate: data logging, narrative, scaffolding (energy balls that light up) and mass distribution. With these machanisms, 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.
Reflecting back, learning what we did, we would have done some things differently along the way. We would have 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.
We would have eliminated more than one input from the mouse - right and left click ought to be the same function, although web browsers make this a bit harder to control. Also, a better input for the rotation of blocks - spacebar works, however, it's not completely perfect. There is nothing difficult about rotating, but for a game that tries to be simple, this is the most advanced feature.