PuppyBot Rescue

You can play PuppyBot Rescue and find more info and activities at PuppyBot Rescue's website!

With this phase of the project, we want to get this game into the hands of thousands, if not millions of kids and see if science concepts can be taught at a younger age (ages 5-11) in an appealing way. Will children play our game and learn from it? Will they play it not because it is assigned homework, but because it's fun? One of the ways we are hoping to do this is by working along with Sesame Workshop to develop a robust, engaging and fun experience. In doing this, we would be able to reach larger numbers of users than past projects.

The science content we are teaching comes naturally through age and experience, and so we're trying to structure our game so that younger children that have yet to master it and obtain a grasp of it, might understand the more complex concepts sooner. Sometimes kids can understand the action, but not the logic behind it - and bridging the two is our goal.

This game is being built on a foundation of knowledge and experience from our past games: RumbleBlocks, Beanstalk, Teeter-Totter-Go!, and Helios.

All of the above games excluding RumbleBlocks were designed and built around research papers written by a Carnegie Mellon University professor, Robert Siegler, based on balancing a beam. For example, see Siegler and Chen, Development of Rules and Strategies: Balancing the Old and the New, J. Experimental Child Psychology 81 (2002), http://www.psy.cmu.edu/~siegler/siegchen02.pdf. With this foundational knowledge, we are able to design the challenge of the game relatively easily, while focusing our core effort on the mechanics and the look and feel.

In general, each game is developed in the course of one semester through the combined skills of a multidisciplinary project team. These efforts are guided by iterative playtesting with children. That is, at many points during the semester children play the game and through direct observation, questionnaires, and interviews the development team learns what works and what does not for the target audience. The game is tweaked and made ready for the next round of playtesting. The teams have produced a few papers documenting this process. Beanstalk is discussed further in http://doi.org/10.1109/IGIC.2013.6659126 and Helios discussed further in http://doi.org/10.1109/CGames.2013.6632614 -- see these papers for additional resources on the game design, on Siegler rules, and on the use of playtesting during development.

Controls and Mechanics

With early RumbleBlocks user testing, we found that the younger the child, the more difficult it was to control a mouse, and even more so, a keyboard (even if told to use just a select set of keys). RumbleBlocks utilizes left and right mouse click, spacebar (alternate for right click) and the arrow keys (also alternates for the right click). We found that using the left click and spacebar to rotate a block was the best combo. More on iterative playtesting to develop RumbleBlocks can be found in the conference paper at http://doi.org/10.1109/CGames.2012.6314570.

With Beanstalk, we decided to remove all the complexity of the controls from RumbleBlocks (click and drag, combination of inputs such as hold a block and press spacebar to rotate, and multiple inputs). Beanstalk was simplified so that now a 5 year old could play comfortably - all controls were just a click - no dragging, no combination inputs.

Over time, we found that the over-simplification of Beanstalk's controls were a bit monotonous. So with Helios, dragging was reintroduced, with touch input in mind - and then with PuppyBot Rescue, flinging the blocks as a new mechanic was incorporated. This allows players that can't completely control dragging some freedom to controlling their object.

Inventory

Since RumbleBlocks, we've been advised to put the entire inventory out on display for the players - something we always tried to incorporate, but never found a justifiable way in doing so.
With PuppyBot Rescue, this was highly considered in the design process, and ultimately - incorporated.

Audio & Instructions

With our first few games, we found that audio, when used as instruction, was ignored if there wasn't an equivalent amount of on-screen visuals. With a lot of collaboration and advice from Sesame Workshop, we reduced and simplified the voiceovers throughout our current game, PuppyBot Rescue. Kids have short attention spans, and we must consider that in our designs.

1. We wanted the interaction to be fun and break it down into its most basic form. How can we make the action of interacting with our game fun?

2. What are some fun mechanics that could reach this goal?

3. How can we keep the game play simple, so the educational objects are the focus?

We began trying to solve these questions by brainstorming and coming up with a series of concepts. In the beginning, we focused on 4 basic ideas encompassing a few different mechanics and ways of interacting with the game.

With those 4 ideas we made storyboards and game documents to better understand where they could be taken; this process was very helpful. A lot of ideas sound really achievable after you begin to walk yourself through how they would pan out.

There has been a great deal of development and changes made to our concept and design along the way.

As mentioned, we started with 4 different ideas. We came up with these by: thinking about what sort of mechanics we wanted to have that would be fun, what would be a cool way to interact with our "beam" that we are using to support our educational content, and keep the focus centered around these things.

What we came up with:

Some of our first ideas were games where you would move an avatar back and forth to throw things on the beam. While you did this a prankster would be constantly unbalancing the beam causing you to rebalance it until time ran out.

Some of our other concepts centered around games similar to games you would play at fairs. These were more simple concepts that were similar to mini-games.

After looking at all the concepts we had, we decided to stay away from having to interact or control an avatar. We wanted the focus to be centered mostly on the beam.
From the original set of ideas, we narrowed it down to three concepts. From there, we began to flesh out the interaction by creating detailed storyboards that walked through the whole experience.

You are be tasked with taking samples of the slime that was building up in the sewers. While doing this, you need to make sure the beam stayed balanced. Once the beam was properly balanced, you would pull a lever to raise the beam out of the sewer. It isn't as simple as you think, not with the baddy bots getting in your way. To keep them from blocking you, you have to slime them knocking them out of the way.

Things on earth have been going missing. Socks, toys, etc. After looking for an answer, we find that they have been falling down into the sewers. To help recover these items, it is up to you to load items onto a beam to take them back to the surface. While trying to recover items, one of the important stabilizing cords break. Now, to be able to get the beam to raise properly you need to fling items out of the water into baskets while making sure to keep the weight balanced. The faster you collect needed items the more points you get, but watch out for some of the creatures living in the sewer that could mess you up!

(This was seen more as a testing mini-game). The tricky pranksters have scrambled 3 beams. Only one being properly balanced. You're trying to get out of the sewer but which way is the way out? It's up to you to figure out which beam is balanced.

From those storyboards, we created mock-ups to show the styling of the art.

After reviewing these concepts with Sesame Workshop, we merged some of those ideas together. They also suggested changing the gameplay so the player isn't stationary, but rather traveling through the sewer. We hoped that this would give the kids a sense of moving through space and progression, and to provide accomplishment.

The earlier form of our current concept, was that you would be pulling a beam up out of the sewer carrying some container full of slime. And on it's way to the top, you had to make sure it didn't spill. To do that, the player has to keep the beam balanced all the way up, trying to stop the efforts of the baddy-bots who are constantly adding and subtracting weight to the beam.

The finalized concept/design we went with has changed dramatically over time. It has come a long way from its simple beginnings, and has turned into a fun game it's currently growing into now.