Team Y!
Creating an Augmented Reality Proof of Concept
The project is still under a strict NDA which will not allow me to showcase the app itself - this is a case study of the creation process.
This project, which is still under a strict NDA was a new experience for me. Being the second major interactive experience I've been involved in, it game a new perspective to the in-and-outs of creating an iOS game. And in my case, a new challenge as the team's Scrum Master.
At the beginning of the semester, we only knew who our Faculty advisor was, we didn't know exactly who was on our team - as one advisor could have more than one team - and who our client and project entailed.
After that first session, we were assigned to our project rooms, handed our briefings and tasked with setting up a first meeting. And although we knew each other from the previous semester, we had to figure out what our roles would be for this specific project. Which at it's highest level, is an AR puzzle/scavenger hunt app targeted to school-grade kids.
With an eclectic team of six, each one from a different country and background, Team Y! had it's first meeting . Héctor was our main programer, being a master of Unity, Julie, an artist by trade wanted to get more hands-on experience in both Unity and coding, which she delivered flawlessly. Robin was our resident programer, a 4th year student from UBC's Computer Science programme. Pushkar, with an amazing portfolio as a designer and art direction was our User Experience and User Interface designer. Seán was our lead technical artist with a background in Motion Graphics and I took the role of Scrum Master.
My main role was to provide the team with anything that they needed in order to perform to their peak potential, and this task started pretty much from day one. We spent the first few hours planning our working space, detailing what equipment we might need from our IT department and what would be our preferred method of communication. At the same time, we had to introduce Robin to the world of agile project management and how to better work with a team as she was the one with the least amount of experience in this regard.
Most of my day was spent fulfilling requests from the team, answering mails and making sure that the whole team worked as a nicely tuned machine. This also required me to observe the team dynamics and behaviours to spot potential differences between the team members before they became a major issue. This was made more simple - at least to me - when we did our team retrospectives.
During the 13 weeks working with our client, we went through many sprints, meeting and reviews. Most of the client meetings were conducted by our Product Owner. After these meetings we held a debriefing session as well as a sprint planning; it was my job to go over the notes and client feedback as well as maintaining a good flow during these sessions in order to have a sprint plan ready to go and decide on the next set of features that would add more value to the product on its next iteration. Every day we also held stand up meeting in which every member would explain what they were working on, what they've accomplished and if there are any blockers that might not allow them to continue; it was my responsibility to clear out as many of these blockers as possible.
One of our retrospectives was a bit unusual, as we did it during an outing and using characters and quotes from our favourite movies to reflect what we think of each team member, giving everyone an insight on where our strengths are and how they perceive us.
As part of the design process and based of what the final app would be, we were tasked with researching different style of puzzle games. And this included a visit to a local Escape Room, where we learned about building an engaging puzzle that could include a social aspect; and for our purposes, learning how to create a series of puzzles that could each be solved in a short amount of time.
We had to work with shorter sprints than what we would've liked to. Being on grad school means that you might have classes and for us, this was the case on Fridays. We had our client meeting and sprint planning on Thursdays, which meant that by each Monday, everyone knew what they were supposed to be working on and we had until Thursdays to have a new working file to show our progress and what features we were able to incorporate.
During the week, we held many rapid testings, specially approaching the delivery date. But also, we held a lot of brainstorming sessions where a lot of the concepts that were once a simple idea, were destilled down to a more concrete feature that we could implement.
When we first got our brief, one of the suggested technical knowledge requirements was Photogrammetry. We took on the task of both learning the process and test it to see if we could incorporate a highly detailed 3D model into the app. This process proved to be both frustrating and valuable at the same time.
We did a lot of testing with different techniques and set ups to get the best possible results. In the end, this process was not incorporated into our final iteration due to time constraints.
After testing a larger setup, we found out that a Lightbox with a rotating base would give us some good results creating the 3D models. With limited budget, time and resources, we had to come up with a cleaver way to build our our Lightbox. In this case, we used an old cardboard box for the frame, cheese cloth for the diffusers and a fidget spinner as the rotating pivot point for our turn table.
A screenshot of what we had at the time. The Spingarde module allows you to build a jigsaw puzzle made out of the different parts of said object.
In the end, we ended up with not only a nice proof-of-concept app for our client, but we learned from both our project advisor and client. We saw him not as a client but as a Mentor; his vast knowledge in the game industry was a beacon guiding us through the whole process.
The physical hand-off was a symbolic way giving him all the hard work we did for this 13 week journey.