The Great Invention Heist
The Great Invention Heist is a 2D drag-and-drop game meant to teach STEM to 2nd-4th graders. I worked with four other teammates to build this game over a semester at Wesleyan while taking a video game development class with Bethesda founder Chris Weaver. I coded a lot of the UI and the game mechanics in Unity/C#, wrote the dialogue, and handled level design and organization. The game was a smash success—it was rated the most fun by students and received lots of acclaim from a panel of industry judges. You can play the game online here!
During the spring semester of my Sophomore year at Wes I took a video game development class that split us into teams of 5 and tasked us with creating a video game that would teach STEM to grade schoolers. Our team decided on the vague idea of a time travel drag and drop game where kids would combine items to create famous inventions. During this design phase I made sure to iron out many of the important details of our game, such as a general story, basic level structure, and game rules, because I knew that laying down these foundations early on would prevent misunderstandings and wasted work. I also made sure we were within appropriate scope, specifically by lobbying for the removal of a planned game mode that I could tell would take more time than we had while not providing adequate fun/learning.
This was the first major team project I worked on, so in order to ensure team cohesion I scheduled semi-frequent engineering meetings with the other two engineers to map out all of the scripts, controllers, and variables we would need and how they would interact with each others' code. We created a modular level system that allowed us to add in new levels with ease, given the right assets, and I personally created a system of reusable modals that were quite handy in our modal-filled game.
We chose to explain many of our STEM concepts through text and diagrams, so I put my English major to good use writing item descriptions, scientific explanations, hints, and witty puns in a style that kids would be able to understand and enjoy. Furthermore, I would work closely with our artist on the diagrams that accompanied much of this text so that kids who were more visual would have a good grasp of what was going on as well.
The crux of our game revolved around combining objects on screen to make bigger, more complex objects. For example, combining an engine and fuel creates a fueled engine, which can then be placed into a plane to make a motorized plane. In order to give kids as much freedom as possible, so that they could explore and feel a sense of achievement and curisoity, we had to allow these combinations to occur in different orders—you could put the wheels of the plane on before the engine, or after the engine, before the rudden and engine or after the rudder and engine, before the engine but after the rudder, you get it. Keeping track of all of those possibilities required a huge amount of organization, so for every level the other level designer and I would create a huge spreadsheet outlining every possible interaction between every possible item (red = failed combination, white = successful combination into new item, yellow = failed combination with explanation on why it failed, to guide the player). Furthermore, as the player progressed the levels got more difficult, which can be seen in the complexity of our spreadsheets.
Once we had a working prototype of our first three levels done, we decided that we needed to actually test our game on some real participants, so we wrangled up a gaggle of cousins, siblings, and kids of teachers to create a beta testing group. We then video called each child and watched as they played the levels, and then asked them some questions. We wanted to see whether kids in the right age group could understand our puzzles and actually learn something from our game. By asking the testers about topics before and after they played the level, and then again after they finished the overall game, we were able to gauge how much information they retained and understood. From our testing we determined that kids were able to understand the concepts we presented, and we also gained various valuable insights about the gameplay, which prompted us to add a tutorial level, increase the number of failed collisions that provided helpful messages, and make other aspects of the game more representative of our user base.
Due to our successful scoping, organization, and planning, we were able to complete five full game levels, as well as a tutorial level. We chose to forgo creating a sixth level, 2_3, so that we could focus on polishing up our game and adding juice. We added in particle effects galore, additional modals, easter eggs, and tested the heck out of our final product to ensure it lived up to our standards. At the end of our class, all the teams sent their games to a class of elementary schoolers, who rated each game based on how fun it was and how difficult it was. Our game was rated the most fun of all games in the class, and our difficult was centered right around the middle, which reflected our desire for it to be challenging enough to be entertaining but not too challenging to be discouraging. Additionally, when we presented our game to a group of industry professionals as part of a competition at the end of the course, they all loved our game and gave us first place, admiring the methods we were using to teach STEM and our dedication to making our game kid-friendly! This game remains one of my proudest accomplishments and most valued projects.
