Navin Supphapholsiri-Assistant Producer
Untethered is a gravity-shifting, two-dimensional side-scrolling platform game that forces the player to think, literally, in new directions. Drehen, an engineer sent to the blacked out space station, Torque, to investigate the blackout and repair the station. He must look at problems in a unique way, due to the shifts in gravity, to solve the puzzles presented to him.
The team consists of five developers with the project lasting a total of 8 weeks. After six short milestones, the final product consisted of seven levels. This postmortem analyzes the positive and negative processes that occurred throughout the development cycles.
What Went Well
1.) High Buy-in/Motivation
From the early phases of pre-production, the constant that remained throughout the project was that everyone was sold on the idea of having a gravity shifting core mechanic. Dissent was always accepted and everyone was able to freely express their opinions. This process promoted collaborative work between disciplines and resulted in unique designs that we as a team are very proud of.
2.) Sufficient User Input
At the end of each of the six milestones, our team had a number of Kleenex testers that provided us with the feedback we needed. In addition, we also had public event and usability testing towards the later milestones. The feedback gave our design team the ability to adjust and tweak gameplay to improve the overall quality of Untethered.
3.) Functional Working Environment
Our development team was located in a breakout room where all five of us were sitting merely a few feet from each other. This provided an adequate working space for our scrum sessions, scrum boards, and individual work spaces. This process brought us together as a team and we all became close friends throughout the project.
As a producer on this project, this was my first time introducing scrum to my teammates. Every core meeting, we would stand in a circle, and with myself as the Scrum Master, I would ask questions about current progress (what have they done since last scrum, what are they doing this scrum, and whether or not there are any obstacles).
What Went Wrong
1.) Feature Creep
As we reached each major milestone, the user input received inspired positive ideas to the design team. Minor mid-project changes started to occur now got a better understanding of our game. Our programmer and artist had to work additional hours to get our new feature ideas in. By the end of development, the feature creep allowed resulted in adding a High Score and Achievement System to our game.
2.) Omitting Necessary Tasks From Estimates
Throughout each milestone, events such as internal testing, public testing, quizzes, meetings, or other unrelated development tasks were unaccounted for from each estimate. Due to the constraint of the time given for this project (2-3 hours per core meeting), these events would encompass the majority of core meetings. As a result, these events pushed back prioritized tasks, causing the team to cut certain features initially planned for the game.
3.) Not Enough Time For Quality Assurance
Our milestones ranged between one to one-and-a-half weeks. This resulted in having approximately 80 total man hours for the week. For the team, this felt extremely fast and many of the things that were addressed in the Kleenex and Sprint Retrospective Reports showed up multiple times on each preceding report. Our team was mainly focused on completing requirements for each milestone that there wasn’t enough time for QA and polish.
Overall, by completing each task and staying on schedule, the team was able to complete a playable demo consisting of seven levels with very minor cuts. This opportunity gave my team valuable learning lessons and the knowledge obtained from this project is something that we will carry forward going into our next projects.
Navin Supphapholsiri – Assistant Producer
Matthew Johnson – Programmer
Taylor Wright – Artist
Steven Kilpatrick – Level Designer
Erik Vaughn – Level Designer