The Great Invention Heist: A Case Study
As a junior at Wesleyan University, I took an intensive videogame development class from Christopher Weaver, founder of Bethesda Softworks. The class was one semester-long team project in which we built a STEM game for elementary school students back to front. After my game pitch was selected, I led a team of student programmers, designers, and artists in the creation of a browser-based game. Our goal was to create an inclusive experience for young students to learn about engineering hands-on. At the end of the semester, we presented our game before a panel of acclaimed videogame industry professionals and were met with raving reviews.
In this case study, I’ll outline our research process, game design decisions, and techniques for teaching science through a digital interactive experience. The game is live on the web today, and can be played here!
Timeline: Spring/COVID 2020
Skills: Project management, game design, UI/UX design, wireframing, prototyping, design systems
High Concept
Each student in the class had to give a 2-minute pitch for an educational STEM game for kids. Here was mine:
Agents from Evil Inc have been traveling back in time and preventing crucial scientific inventions from being discovered. Because of this, modern technology and our way of life is at risk. Only you, the player, can fix this! Good Inc has hired you to follow Evil Inc’s trail and re-invent each discovery.
In each level, you’ll travel to different time periods and meet inventors. Their laboratories will have items and tools, and you’ll put them together through drag-and-drop puzzle games to build each invention. In the process, students will learn a little bit of history about the inventor and how each invention works.
My pitch was voted one of the top four in the class, and thus, I became a “producer.” I had the opportunity to put together a carefully hand-picked team and set out to build a game.
User Research
With the basis of our game concept in mind, we conducted an initial round of user research at our local elementary school. Our goal was to speak to students grades 2–5 to determine their favorite STEM experiences, as well as teachers about how kids of this age best learn technical concepts. We also wanted to understand what kinds of games, media, and entertainment these students were enjoyed, which shaped our interactive designs.
To gather answers to our questions, we went into classrooms during the school day and hung out with kids. We chatted with them about what they liked and didn’t like and asked questions about their latest projects in their Makerspace. Our team also spoke at length with teachers about their students’ attention spans, what kids are most enthusiastic about educationally, and what games they played in class.
Going in, we already had a pretty solid idea of what our game was, but were still figuring out exactly how to convey STEM concepts. Our first instinct was to incorporate short animated videos that explained foundational ideas. To test this out, we showed a BrainPop video in each small groups and asked kids a few questions about what they learned.
Our biggest insights were:
- Elementary schools, and their students, were not the same as when we were kids. These kids were smarter, more technologically adept, and super curious in schools that promoted advanced STEM.
- Young students love project-based, hands-on learning — especially in STEM. The students we spoke to about science class were most enthusiastic about demonstrations where they were able to physically do, build, or interact with something. They also seemed to remember the most content this way (this suspicion was confirmed by teachers).
- Kids today have very low attention spans. Sometimes it was hard to engage these kids in conversations longer than 30 seconds. However, they conveyed to us that they were able to go home and play hours of video games on end.
- Our educational videos were ineffective. Although the students were excited to watch our video, they didn’t seem to actually absorb much educational content from it. We scrapped our this idea.
Initial Gameplay Brainstorming
With our original game concept validated by our user research (a hands-on engineering game to build inventions), we set out to design the details of the gameplay. Our design goals were:
- Create a hands-on interactive learning experience through a digital platform. Although this was already a core pillar of our game concept, it became clear from our user research that this was of key importance.
- Teach a wide breadth of knowledge in a number of areas. Rather than focusing on one niche topic, we wanted to use engineering as a platform to teach many scientific concepts.
- Allow players to learn through both failure and success. Rather than just rewarding the right answers, our goal was for users to understand failure as a learning opportunity.
These goals drove our gameplay and UX decisions.
UX Design
Comic Mode
After lengthy brainstorming sessions, we decided our levels would each start with comic-style textbook science explanations. In comic mode, players would flip through graphic animations with minimal text that would explain, for example, electrical resistance in a wire. This foundational information would give students the background to successfully build an invention. We branded this “comic mode.” As the UI/UX designer on the project, I was then tasked with determining how these screens would work.
Workbench Mode
I also began to think about the drag-and-drop mode (or “workbench mode”), which was fairly simple given there are many existing games with similar gameplay. This screen needed an inventory of items with which you could build an invention, space to combine them, a dialogue box with explanations from the inventor, and other basic UI elements (like a progress bar).
We also decided to create “learn more” modals which would provide additional scientific context about especially important combinations. This was a great feature that allowed us to input extra teaching moments in each level. These modals were accessed by a button labeled “How does this work?” in the inventor dialogue box.
Level Design
Our level design sub-team consisted of myself and two other students. Our level design process involved extensive research on how these inventions actually worked, shaving these down to elementary school-level STEM concepts, then figuring out each piece of an invention and how they fit together, and finally writing all the dialogue and text.
The beginning of researching each level was one of the most difficult aspects of designing the game. None of us being electrical or mechanical engineers, we had to learn how these inventions worked ourselves to the point where we could teach it. From here, we had to pick out a few core concepts we wanted to teach, such as density or conductivity. Then, we chose items that made up an invention and best conveyed our core teachings, such as a filament for a lightbulb. We called these items “props.”
Combination spreadsheets came next. These displayed every prop and what would happen when they were combined. Interactions were classified as either successes (in white), misfires (in orange), or fails (in red). Misfires were combinations that seemed probable but weren’t correct. These were a great opportunity for learning — we’d reveal bits of dialogue that would steer the user in the right direction at these points.
We aimed for each theme to grow in difficulty and complexity with each invention. You can see that we achieved this through the progression of our combination sheets.
Balance proved to be a huge challenge during this part of the design process. If a level was too difficult, students might get too frustrated and give up. Too easy or dumbed down, and they’d be bored. Mihaly Csikszentmihalyi’s concept of flow explains this well — our goal was to keep players in an optimal state, which was highly engaged and challenged (but not too challenged).
In conjunction with flow, we enforced the concept of “guided progression” in our game. By grouping STEM topics together, players could use information they learned from previous levels in upcoming levels, which proved to be a very satisfying feeling.
The next stage in level design was writing the text and dialogue. One team member and I collaborated on writing each level in its entirety, which involved crafting text for comic mode, prop descriptions, and “learn more” clues. The most taxing was the dialogue — for each yellow and red box in the combination sheet, we wrote a little exclamation from the inventor that would guide the player in the right direction.
When all this was completed, we handed off our content to our illustrator, who brought our ideas to life.
Aesthetic Style
Our visuals followed three main goals: that the aesthetics were clear, cheery, and characterful. Because many of the STEM concepts in the game could appear intimidating, we used art style to keep things playful and support the learning experience.
Art & Illustration
I was incredibly lucky to have an unbelievably talented illustrator on my team. She singlehandedly drew the inventor caricatures, each prop, comic panels, and diagrams. As you can see, these were all very approachable and added whimsy to the game. Her skilled work truly created the joyous feel of the game.
UI Design
I wanted the UI’s visual feel to match Molly’s art but not distract from it. I created a defined style system with cheery colors and imperfect shapes that was fun yet simple. I chose a display typeface commonly used in children’s picture books and paired it with Univers, which would be highly legible as body text. The buttons, modals, and tooltips all have the feel of almost being cut out of construction paper. Their shapes would stay consistent throughout the entire game.
The UI can be divided into two categories: overarching game screens and level-specific screens. General screens maintained the blue and yellow color scheme, tying the entire game together.
Outside of this primary scheme, each level had its own look and feel, despite having the same UX layout. This aimed at creating an immersive experience for the player — we wanted you to feel like you were really building a blimp in Ferdinand von Zeppelin’s hangar. Thus, I worked with our illustrator to create level-to-level backgrounds and UI components.
Beta Testing
About halfway through the development process, COVID-19 struck the United States. Wesleyan shut down and we had to complete the project remotely over Zoom. Our team adapted amazingly well to a new workflow, but we were faced with other challenges.
Originally, we were going to beta test our game in-person with kids at the local elementary school. Obviously this event was cancelled, but we still wanted to do playtesting of our first three levels. Our team reached out to friends and family with young children to play our game over video conference, allowing us to observe their interactions and responses. In the end, we successfully ran our own independent virtual beta testing session with ten children ages 8–13.
This process proved to be instrumental in understanding our users and improving our game. We made several small changes based on insights from beta testing, but the two largest were:
- Create an interactive tutorial level. Players seemed most confused during the first level of the game, but got the hang of it as they went. We built a tutorial level that allowed users to familiarize themselves with the gameplay before getting to the educational content.
- Increase the number of misfires and possible combinations. Watching kids build these inventions revealed many ways to put things together that we had never thought of. In response to this, we altered our combination charts, allowing for more combinations, and added more guiding misfire text.
- Implement additional methods of feedback. To clarify and emphasize failures, misfires, and important STEM concepts, we furthered our use of audio and visual feedback through sound effects and animations.
With this knowledge in hand, we continued the development process and built three more levels.
Reception
After publishing our game online, our professor organized a virtual “carnival” for elementary school students to play our finished games and provide feedback. About 75 children played the completed version of the Great Invention Heist.
Finally, our team presented the Great Invention Heist before a panel of videogame industry professionals, ranging from entertainment giants to small developers. We walked them through our design process, gave a live demo of our game, and outlined a marketing strategy. The panel, many of whom had been judging student-made STEM games from this class for years, met us with astonishing praise. It was an incredibly rewarding way to end an intensive, curve ball-filled development process.
