Smash! A Computational Puzzler for kids who don't like Puzzles.

Categories:

Tools:

Unity, Photoshop, Illustrator

Downloads:

Summary

A tablet game for 7- to 11- year old boys with social-emotional challenges, created to include Computational Thinking.

Goals

Our goal for this project was to take an opportunity of "free choice time" in the client's classroom and direct the kids to a new kind of game they tended to avoid: puzzlers that involved the kind of problem-solving that proponents of Computational Thinking believe will transfer to experiences beyond the game itself.

Design Choices: A Before and After

One of the biggest barriers our team discovered to kids preferring puzzle games is that for many low-SES kids, age-appropriate puzzles have an on-ramp of learning that is too steep. They often quit before beginning to master how the game is played. One of the biggest goals and challenges for this game was our pillar of learn-ability. The game needed to wordlessly teach beginner players how to play the game (many of our audience were nonreaders or beginning readers), without (a) being too difficult and (b) without appearing to pander or talk down to them.

We started playtesting internally with our team by week 2, which was critical to the success of the fun of the game. But the downside of this is that when we were ready to make our first digital prototype, none of our team members were unfamiliar with gameplay anymore. What this meant is that what was fun for us as a team were these very large levels with tons of features, a huge board, and multiple ways to win. Here's what a picture of the gameplay looked like at that stage.

However, we quickly learned when we put it in front of our audience that even explaining the rules and throwing them into one of those was too much. We could have simply "dumbed down" our levels--plenty of teams do that--but underestimating player ability levels is never a road map to a fun experience. We believed that with the appropriate onboarding, our kids could enjoy the same puzzles that adult players could. But how? Luckily, around this time Francisco Souki gave a great talk in one of our courses about puzzle design. We totally changed our approached to thinking about each level as serving as a lesson plan, as part of a larger context to the game.

Developing better learnability was our method, and we had two tools for doing so: paper prototyping, and a spreadsheet which tracked what each level taught in relation to the others. We started using paper playtesting with flat interfaces and post-its rather than the board-game style we’d been using previously, in order to test the flat interactions of an iPad screen.

Here's an image of what an early level looked like after we used those tools.

The later levels look nearly as complex as the original shown above: we only removed the complexities that were equally un-fun for our adult players, such as multiple-tiered buildings. We imagine that with the proper onboarding, past the 30 levels we ended up developing, our audience might enjoy those complexities as much as our internal team did.

Outcomes and Takeaways

One of the biggest lessons from this project is how quickly you become removed from a context in which you can accurately judge how easy or hard your own games are. This is why having a good supply of "tissue testers" and an unwavering dedication to being ruthless about your own feelings about difficulty are both essential.