Rubber to Iron
Rubber To Iron is a web game created in collaboration with NASA and ASU to educate teens and young adults about the Psyche Mission in a fun and engaging way.
Play our game at psyche-capstone-web-projects.web.app!
What is the Psyche Mission?
The Psyche Mission is a mission to travel to an asteroid named Psyche to learn more about its content and history.
To learn more about Psyche, visit psyche.asu.edu.
From left to right: Emily Avey, Kalvin Kouch, Christian Guarin, Andre Smith, Wilson Gip
UI/UX Design
Artist
Programmer
Artist
Artist
Programmer
UI/UX Design
Programmer
Music
Programmer
As the first quarter into the project, most of our time was dedicated to setting up our team and the game.
Team organization
Workspace set up (Trello)
Ideation
Research
Design
With a good idea of what we want to make, we fully dived into the implementation of the game.
Set up GitHub Repository
Set up Unity workspace
Implement Design
Feedback
Iteration
We established our communication with our sponsor and our teammates as our very first step. We decided to meet with our sponsor, Cassie Bowman, once every two weeks through a video call. Aside from those meetings, we stayed in touch with our sponsor through our dedicated Slack workspace. Our internal communications with the team primarily took place in Discord, where we discussed task assignments, held regular meetings, and helped each other whenever needed. The versatility and organization of Discord, with its text and voice channels, made it easy to communicate with each other.
While we worked on this process, we ran into some challenges that greatly slowed our progress for our project. Particularly, we:
Struggled with communication and motivation.
Didn't get much work done because some team members were unclear what their specific task assignments were, or where to begin.
However, we resolved these issues after a couple of weeks by:
Meeting 3 times a week to make sure that everyone was assigned a task that was related to the sprint goals.
Increased the granularity of task assignments. That is, we broke down larger, more general tasks into multiple smaller, more specific ones.
Trello was our main task management software. We updated tasks every sprint, which were 2 weeks long, and kept track of their statuses throughout the sprints. Each task was assigned to different members of the team who were capable of completing the task. With this organization of tasks, we were able to keep stay on track and stay organized without feeling the pressure of time or overwhelmed by the number of things that need to be done.
As we started narrowing down what kind of game we wanted to make, we decided to conduct a competitive analysis on games that were similar to the kind of game we wanted to make. We looked into successful side-scrolling games such as Super Mario Bros, Limbo, and Terraria. Our key takeaways from this analysis was that we wanted to create fair obstacles that would get the player thinking of how to progress, but not too overwhelming that the player loses sight of the progression.
Our user flow map helped us identify and organize what we needed in order to make our game's user interfaces. Ideating what information would need to be hosted on each screen based on user needs greatly helped us come up with a layout that we would later present to playtesters. Additionally, writing the general "plot" of the game served as a useful guideline as we further developed our ideas. Fleshing out the flow also helped with the pacing and development of the story, as well as map out any challenges the player might face during their journey in the game. Since there are some novel terms used in these diagrams, we added clear definitions so that every member is on the same page about what unique words may mean in the context of the game.
We compiled all of our requirements and designs into a live document, which we will continue to use throughout the project. This document helped us keep track of all of our assets and code and develop the general idea of the game. The RDD contains much of our documentations, such as storyboards, individual assets, and progress on the overall game.
After all the ideation and research, we were finally able to step into designing the game. We started with sketches and wireframes, then moved on to higher fidelity mockups when we reached a satisfactory point with the designs. We eventually would divert from some aspects of the design as we evolved the game, improving its usability by removing confusing or overwhelming features.
We used GitHub to have multiple people working on the project. With it's commit tracking, we were able to incrementally develop the game and tackle issues as soon as they arise.
For our project workspace, we used Unity. While our team wasn't experienced in Unity, there were a lot of resources about it since it's such a common tool. We were able to run and test the game directly in the workspace and had an easier time arranging the interface. In the early stages, we used placeholder shapes like triangles and squares to indicate the player character and interactable objects. As the game became more fleshed out, we were able to update the graphics into a cohesive and aesthetic game.
We used User Testing to get more ideas on how to improve our web game
We found out that we should try to have a game that gives the users different options instead of one path.
In addition, we decided to implement a puzzle feature to make the game a little different than just a dodging game.
Level 1
Level 2