HOMEBOUND: Learning through Play
This semester I worked on a challenge by Two Sigma Investments as part of school work [Product Studio] along with four more teammates to build a game experience to help children learn the concepts and logic behind coding.
Halite is an Artificial Intelligence programming challenge created by Two Sigma, where players build bots using the coding language of their choice to battle on a two-dimensional virtual board. Their targeted users are people with background in coding.
Challenge: How might we use games like Halite to make learning to code experience for elementary and middle schoolers fun and engaging?
Initial findings
We spent a lot of time trying to understand the problem, which we call unpacking the problem. We started off by questioning the challenge we received, are we trying to teach syntax? Is it the logic of loops or conditional statements? Are the children already familiar with basic coding concepts? Should we focus on the problem from mathematics perspective or language? Is it about building something or is it about understanding logic in a fun way? Is it about solving a problem? and so many more questions that we needed to answer before we jumped on a solution.
We started looking at other projects which attempted at solving this problem such as Halite, Scratch, and different physical games. Our first attempt at this problem was to create a system diagram based on what we learned from other projects and figure out potential wedges that we would want to focus on.
Potential Wedges:
Accessibility:
Halite’s current players include high school students, coding enthusiasts and senior engineers; mostly someone with a coding background. Halite could make its installation and game entry easier to attract those who don’t really know how to code before, such as elementary school kids.
Instant Visualizations:
Halite requires players to create their own bots before testing them in the visualizer on the website, which is not very straightforward. If Halite could let players code, compile, run/test their bots altogether online, it would make the game more engaging.
Education:
For those who don’t have a background in coding, they might have no idea how to start and modify the starter package. Halite could provide some online tutorials for each programming languages so that the players would know how to begin writing their own bots and even be excited about coding.
First iteration
Keeping all the findings in mind we decided to focus on creating a game for children with no background in coding. We wanted to help foster children’s metacognition and encourage them to think logically in a fun way. Inspired by Seymour Papert’s concept of Teaching Children Thinking, the objective was to have a ‘play with a purpose’ focus, where learning would be embedded within the gameplay. The idea was to give children the power of innovating logically without having the constraints of textual syntax to deal with, as this could be developed at a later age.
Below is our refined system digram. We decided to call our game Homebound.
Narrative: Homebound will introduce kids to key coding concepts in a fun and engaging environment that leverages a unique multiplayer element that increases understanding through competition and collaboration.
During our first attempt, each member drew individual storyboards visualizing their own ideas. We performed silent voting, and after multiple iterations we sketched out a team storyboard (last one).
Soon we turned the storyboard into an interactive mockup and tested it out with 15 middle school children from Roosevelt Island School. We also asked for feedback from fellow classmates, professors and industry leaders.
Mockup
The first high fidelity prototype can be found here: https://xd.adobe.com/view/943acd5a-5f88-4284-8dfe-86aca41d6cd4/
User Testing
From the user testing at this phase, we wanted to show our mockup to children and see if they can figure out the storyline and the purpose of the game. We also wanted to investigate about their own process of learning and their daily activities trying to find a link that we can leverage. We talked to teachers along with children to evaluate the game’s compatibility on their knowledge level/educational system.
Some of the feedback that we received were that children wanted the game to be more visual. They wanted a more immersive storyline and ownership of the game such as the characters. They liked the fact that it was a web app which meant more accessibility as different kids play on different devices. They were confused about how to evaluate success in the game. They also showed a lot of interest in multiplayer mode. One of the interesting finding was that they preferred cooperative game mechanics over competitive for the multiplayer mood.
The experts told us we need to focus on differentiating ourselves from games or resources that are already out there. What is special about us? Why do we want to build it?
Second Iteration
After receiving feedback from the children and experts, we decided to go over our game architecture and create a blue print of how we imagine our game to work. Keeping in mind that none of us were game designers, this approach helped us visualize our thought process. During the process we evaluated potential ratholes we might get into and what are the different resources we can use to build the game and how the game will flow.
After getting a sense of how we want the game flow to be, we iterated over our system digram and decided on what we want to build as a proof of concept. Due to time constraint, it was not possible to build the entire game. We decided to not build features such as sign in which is not crucial in testing out the product.
Once we had our game flow ready we decided on few feedback that we wanted to focus on for this iteration based on results from the user testing. We wanted to focus on the gameplay since it was a bit confusing to some people. We came up with a exploratory storyline for the game to keep the kids invested and give a sense of purpose to the game. Due to short timeframe it was crucial for us to decide on one key feature of the game and keep iterating over it. As a team, we decided to work on single player mode and keep testing it out.
We built new assets for the game to make it more visual. We changed a lot of the interactions of the game to make it more intuitive and fun. Below are few examples of new assets
Later we built out the game using simple HTML5, CSS and Javascript. The first version of the prototype/ demo can be found here: https://github.com/HaliteJr/sprint2
Mockup:
Demo:
User Testing … again
We performed user testing on the new demo and received some really important feedback from industry experts. We showed to Greg Pass, leland rechis, Michael Corey, Meg Ray, Champika Fernando from Scratch team, Andreas Karatsolis from MIT CMSW.
Some of the important feedback we got was that we needed to focus on introducing the problem to the children in a simpler way. Our interactions were still not intuitive enough. We needed to focus on a targeted group of users either with or without a background in coding. For the game theme, we needed to keep in mind that we want to address a larger group of children who may or may not have an interest in the space theme. We needed to show a connection between how this game taught children key concepts and a mind set of required for coding. We were lacking a way to evaluate the success rate of the game.
Third iteration
For our third and final iteration for the semester, we decided to recollect all the feedback we had gotten over time and incorporate the most important feedbacks. There were three main features that we decided to focus on to make the game more appealing:
- Game tutorial: We added a game tutorial at the beginning of the game along with a storyline which introduces key game mechanics to make it easier for participants to start playing.
- Customization: We added a feature to allow our kids to customize their own ship and name it to give them a sense of ownership of the game.
- Gameplay: We redesigned our gameplay to make it more intuitive and less confusing. We made it more progressive than before. Users start with simpler steps and dive into deeper concepts as they cross levels.
Below is a demo of the game along with explanation.
Second Demo
Github repo: https://github.com/HaliteJr/sprint3
Inspirations
From our research we found a lot of interesting game experiences but some of the most inspiring ones were Zoombinis, Scratch, physical games by Think Fun, Python Turtle, LOGO and Halite.
Key Learning
The experience has been extremely rewarding and I am glad I will keep working on it moving forward. There had been multiple difficulties but we overcame them as a team. For example, we had a decent product that the kids loved but while we talked about it, it was difficult for the audience to understand the game without playing it. The level we had built midway was too advance for some people, so we had to take a step back and recreate a more simpler level. We were struggling to keep it fun and engaging while introducing how the concepts can be applied to actual coding in the real life without making it more difficult. None of the team members were game designers or web developers, so it was a huge learning curve for the team.
My Role
My main role was Lead Engineer and Product Manager for the team but similar to a startup where we wear different hats I majorly contributed to the design of the game mechanics. I performed and arranged the user testing sessions. I have a formal background in Design and Engineering, which allowed to play different roles extensively.
Future Steps
We will be continuing with the project for our next semester as part of Startup Studio at Cornell Tech. We have few industry experts on our advisory board who will be guiding us. Moving forward, below are few things we aim to improve upon:
- Expand on single player mode
- Investigate multiplayer opportunities
- Implement a better backend system to help with the expanding
- User test with more children
Thank you team members and my mentors for guiding me in the process.
Follow me on Twitter or shoot me an email (nisanoshin@gmail.com).
Always looking for feedback and cool projects to work on.
