Micro Bittle is an educational game developed for the BBC micro:bit microcontroller, and designed to help sixth-grade students understand the difference between input and output in an experience that combines physical computing, a virtual world, and problem-solving. The game is set up so that it can be facilitated by a teacher during school lessons, for a class of sixth-graders divided into groups of two to three students, with each group using a computer and a variety of hardware components.
The project was developed for Lourdes (Lou) Karas, who is the Director of the Center for Arts and Education at West Liberty University. The center “is a multi-faceted hands-on learning laboratory and resource center focused on the integration of the arts, creativity, and technology,” and its purpose is “to provide innovative professional development programs, resources and services to educators, students, teaching artists and others interested in the role of the arts and creativity in Pre-K to 12th grade education” (Center for Arts & Education – WLU).
The project team members were Xintong (Sandra) Liu as artist and producer; María Laura Mirabelli as game designer and assistant producer; Yuchen (Robin) Xie and Muru Chen as programmers; and Hui Feng as programmer and technical artist. The project’s advisor was Ruth Comley and its faculty consultant was John Dessler.
Team Micro Bittle’s goals were to create a game that combines physical sensors, the micro:bit controller, and a web-based game developed with Unity WebGL; to teach students about input and output in technology by showing them how data transfers can be used to meet specific in-game goals; to ensure that the game is engaging and sufficiently challenging, yet not frustrating, for sixth-grade students; to implement game features that allow the experience to be replayable, instead of a “one-and-done” activity; and to develop a user guide to help teachers use the game as part of their lessons.
The project’s deliverables were files that can be uploaded to a West Liberty University server to run the Micro Bittle website; documentation on how to upload and set up said files; the micro:bit code that must be installed in any micro:bit used in the Micro Bittle game; a list of hardware components necessary to play the Micro Bittle game; and a teacher guide for teachers facilitating the Micro Bittle game.
From the start, our team had multiple advantages. The first one was working with Lou as our client, given that she has worked with the ETC on projects before and has a good understanding of our process. She was able to provide us with relevant information and clear conditions and limitations from the start, and helped us coordinate playtesting with elementary school students and teachers at West Liberty University. We also had the support of Ruth and John, who have ample experience in projects of this kind and guided us in the best directions to take. They gave us constant feedback and called out areas for improvement, which we are immensely grateful for. Because of this, we were able to meet our client’s major requirements, which included using the BBC micro:bit, teaching students about input and output, designing for groups of 2-3 students, and allowing replayability and the use of the game for multiple class sessions.
Another aspect of the project that went well was the consideration of educational goals. We set up playtesting sessions from the start to learn from our target audience (for example, which sensors do 6th graders like using, and which are too confusing for them? Which beetle shapes are most appealing to them?), and we were able to visit different schools with the help of John Balash and Anthony Palyszeski. We also reached out to teachers to get their advice and suggestions on the game and its teacher guide. One of our teammates had previous experience as a teacher, so the first playtesting sessions were led by her, but other teammates quickly felt comfortable working with children and were able to facilitate sessions later on.
This project was particularly challenging because we had to work with technology that our target users (both the sixth graders and their teachers) can find foreign and intimidating. Many of the school groups that could use our game have never seen a micro:bit, coded, or wired components. Their teachers might feel confused or overwhelmed by the technicalities of the process. Therefore, we had to understand the technology very well ourselves, to be able to develop for it and to design a game that any teacher could facilitate and any student could complete. Hence, our team worked on becoming familiarized with the components we would be using from the start, so settling on how to develop a game for them was a quick process (both in terms of game design and hardware-software integration). Additionally, we were dealing with hardware components that exist in a myriad of styles, depending on their manufacturer (for example, expansion boards come in a variety of configurations, sensors have differently labeled pins even though those pins have the same functions, and data readings are not always exactly the same). Therefore, we had to make our representations and explanations of components for the game as “universally” understandable as possible, and ensure that data values fed to the game are always of use regardless of variations. We believe that our attention and efforts to tackle this will pay off in a positive way.
Finally, we confirmed through playtesting that the game is exciting and educational for our target audience. The game design works well to teach and engage, and aspects like the art assets and in-game visual effects are satisfying to interact with. For example, students really enjoy the mentor character model (they think he’s very cute) and found maze-solving fun due to the obstacle-breaking effects and gem collection effects. We also noticed how excited students were to “play”with wires and see hardware components turn on when connected to power, so we leaned heavily into these moments. Teachers who reviewed our teacher guide and game approved their design and were impressed by the experience we wanted to accomplish, while also complimenting the general implementation of the website.
These things said, we must also acknowledge the issues we faced throughout this semester, and particularly those we couldn’t quite solve. Our biggest problem was the lack of an organizational structure to help us communicate effectively, be accountable for the different tasks the project required, and maintain a realistic timeline and expectation of our work. We communicated frequently in-person and via a team Discord channel, but information often got misunderstood or lost among long lists of messages. Our producer set up a Trello board that we used at times, but we never defined a standard way of navigating the board as a system. Similarly, our designer set up a design document that was constantly referenced and used to tag other teammates to signal new tasks, but the document wasn’t constantly checked. We didn’t have an “master” system by which every teammate could or should report their daily work and responsibilities – thus, we had no clear avenue for accountability.
Different struggles stemmed from this lack of organization throughout the semester. Our unclear timeline goals led to a very stressful end-of-term for the entire team, when we had to compensate for work that hadn’t been completed in previous weeks. Thus, we were unable to playtest several parts of the game with our target demographic, and the game’s final version could be much better in certain respects such as UI and sound, as well as some mechanics. Most of what we intended to implement, test, and iterate on during the second half of the semester only made it to implementation, with only a few of these features having minor testing and iterating.
When faced with the reality that our project fell behind, the team considered which factors had worked against us: some of us felt that the project was overscoped; that we dedicated too much attention to playtesting and neglected development; that development updates to the designer, advisor, and client were scarcer than they should have been to receive feedback and implement it in a timely manner; that task assignments and details were not always understandable; that we should have paid more attention and dedicated more time to UI design and testing. At the end of the semester, based on conversations with our faculty advisor and consultant, we understood that all of these could have been tackled earlier and solved successfully with a good system of organization and a well-defined communication structure. Our difficult experience serves as an important lesson for all the members of the team. Though we got along as individuals and enjoyed each other’s company, that wasn’t enough to work together in a way that was consistent, clear, and ultimately satisfying for everyone.
As a conclusion to our project, we would like to reiterate our gratitude to everyone who helped us in our design and development process, as well as those who facilitated our playtesting plans. We received valuable suggestions and feedback from our client, advisor, consultant, other faculty, and school teachers that greatly informed our work in the best ways possible. Playtesting on numerous occasions with our target demographic granted us insight without which our main goals couldn’t have been achieved. We recognize the shortcomings of our process and how we could have improved as a team, and admit that the project could have turned out to be more polished and successful if we had addressed our organizational issues from the beginning. We all learned a lot from the requirements of this project, from working with each other, and from the journey this semester represented.