Project STEAMineer was focused on incorporating technology into maker-centered learning to promote student interest in engineering, technology and art. Past instances of technology for maker-centered learning, such as robotics kits, circuit kits, and maker kits provide students with opportunities to create within a pre-determined framework intended by the designer. Our hope was to find a way to incorporate technology so that it would be accessible to our audience while still maintaining student agency and supporting student-directed outcomes. We wanted to create a technology-based tool that students could implement based on their own ideas. We were a team of 6: Max Hsieh (programmer), Mimi Wang (programmer + designer), Mia Zhang (fabricator + designer), Yifan Deng (designer), Isabel Yi (co-producer), and Marissa Doerger (co-producer). Our advisers for this project were Scott Stevens and Dave Culyba.
We ended up forming a partnership with Nina Barbuto and the team at Assemble Makerspace in Garfield. The Assemble Makerspace became our client for this project and the plan was to create a curriculum, digital game, and Arduino-based prototype that could be implemented in Assemble’s Game Design Summer Camp. However, when everything was moved to remote work, our deliverables changed. We created an instruction guide, Arduino controller, and digital game. (The curriculum was changed to be an instruction guide to support facilitators and kids collaborating at home during the pandemic.) Our game is a horizontal scroller that features a submarine collecting crystals to restore power to Atlantis. The submarine has four main functions that players interact with: motion, battery power, collect (for crystals), and attack (for sea creatures that take away crystals). The game can be played with a keyboard and mouse/touch-pad, but the team also created a controller composed of Arduino Inputs that players can choose from as an alternative to keyboard controls. The Arduino inputs include a button and joystick, but they also include more unique inputs like sound, temperature, and light. Players can test different combinations of the inputs before playing the game to try to find the best combination.
As a team we felt slow to start. There were lots of paths to consider and we all had different ideas in our heads of the project outcome. Once we started prototyping and regularly playtesting, we made significant progress. For three weeks in a row the team playtested at Assemble with 3rd-5th grade students in the afterschool program. We were able to iterate our game and our process for controller construction based on feedback from our playtesters. It helped us take a pulse for what was meaningful for students like collaborating with their peers to play and having a meaningful story as part of our experience. We learned to trust kids with hot glue guns and that they like stickers.
While we were slowed down by the pandemic, we were able to quickly regroup, reorient our project to make the most of the circumstances, and continue playtesting. Since we were already developing a facilitated activity for kids, we decided to switch our audience to kids at home with caregivers instead of kids in an afterschool program. We hosted four remote playtests with two ETC families and two Schell Games families. This forced us to create an experience that could operate independently of facilitation by the team– something that we had not accomplished in our playtests at Assemble. In our second remote playtest our efforts seemed to come to fruition. With an updated controller design and a testing space as part of the game build, we had a playtester successfully experiment with different combinations of Arduino inputs and submarine functions. What’s even better, is that he was excited to do so, and continued playing because he wanted to.
Although we did not reach a point where students are physically making their own controllers, we did make progress on the path to that point. We created an experience where students can assign inputs to functions and with more time, we could begin testing how we can get students to create their own control panels that the inputs can be applied to. Another success of this project is that in spite of our murky start, we have a clearer direction for what this project could be. We also received positive feedback about how our game decisions support the goals of the project. We kept the game simple and used repeating mechanics to support controller testing. Having four mechanics supports multiplayer interactions. We also made the game short to encourage playing again with different input configurations. Making the goal crystal collecting puts the challenge on the player to beat their own score or challenge a friend to play. Lastly, we were told we communicated well over Slack once things went remote.
Trying to manage content and expectations at the beginning proved to be challenging and could have been better. With no client initially and our project adviser also being a stakeholder, we had trouble navigating what our project should look like and asking the right kinds of questions to get there. We also reached out to over 10 subject matter experts which added lots of additional information into the mix. The lack of direction definitely weighed on the team. Our first remote playtest could have definitely been better. We underestimated the challenge of combining so many disparate elements that had been developed independent of one another. The instruction guide made claims the game couldn’t support and the controller ended up requiring three people to operate it, which our playtesters reported as feeling like they were “breaking” the game. If we failed in the first remote playtest, our second remote playtest was definitely a success. The experience also seemed to be very frustrating to our playtesters which felt like the worst part. While we were able to make substantial strides in our experience (the testing space and new controller design were a direct result of this particular playtest), it feels terrible knowing you are giving someone who is sharing their time with you something that could be better.
Although we message frequently on slack, we also needed to do a better job of sharing progress with one another. In a project room when something goes right, someone exclaims and everyone gathers around their desk. When you’re working remotely, there’s no one to check out your monitor. This resulted in multiple occurrences where things were given to playtesters and no one else on the team had the chance to double-check it. This also led to limited iteration on later game elements like our sailor characters. Lack of diversity and variation among the characters is bad for distinguishing the sailors on the submarine and could present an unintentional barrier of access to our experience.
For our final deliverable, we will be reporting on our findings for the semester, and hope to deliver an instruction guide, Arduino controller, and digital game to John Balash at the ETC. We will also be including digital files so that John or anyone he shares it with can laser cut or 3D print a more robust casing for the controller inputs. We learned how involved the process of supporting student-made controllers can be. Future applications could also be adapted for more at-home use. Especially in a moment in time where many people are quarantined at home, having an activity with a guide that could be easier for more naive guests to follow would make our activity more accessible to a wider audience. We also learned more about best practices for maker-centered learning like using open-ended prompts and providing the right amount of constraints so students are supported creatively and have room to make their own unique outcome. We also learned that while there are successful examples of products that support open-ended, student-directed learning and creation it is something professionals continue to experiment with and be challenged by. Our 15 weeks of research, prototyping, and playtesting in the space are just the tip of the iceberg.