Shared House was a very interesting project for me. In the it was the first major project I'd undertaken for a few months, it was the first project where one person or one designated group of people were the creative lead, I was simply there to provide them with tools and working scripts for the game, it was also the first project in a while that I'd been project manager for. So for all of these reasons, including that it was VR, the project excited me, and overall, I'm very happy with the outcome. Aside from the obvious "I didn't spend my time on this project very well." or the "I know I definitely could have handled managing the project better." the most major things that went wrong with the project were scope and understanding of the 3rd party tools we used to make the game.
The reason scope was a problem is most definitely not for the reason you're probably thinking of right now, our scope was too small, if anything. While it made sense, and in the end, my group still ended up working down to the bone right up until Brass Razoo, the exhibition our game 'premiered' at (which is still an awesome thing I'm trying to wrap my head around). But in terms of assigning tasks, well there wasn't much to assign to the three programmers in the group. The majority of the work that the programmers needed to have done was completed by the third week in, and the rest was basically Noah, our designer figuring out how to keep the player intrigued by this person the player has never met (which was likely the greatest design challenge in VR). So once we reached this point, I struggled to give tasks out to the other programmers in our group, and I felt bad for it, like I was a bad project manager (I'm definitely not the greatest, but I'm trying) when in reality I had no clue what could be done. So scope was definitely a problem, and it most likely would have been much more of a problem if we already knew how to use the third-party tools we used.
VRTK by stonefox is a very coherent and in-depth tool for VR that our group had the ability to use throughout this project. Unfortunately, because the majority of the team had not worked with Virtual Reality before, a large portion of the project was dedicated to learning how the Virtual Reality Toolkit fit together, and how we could adopt it into our game. This meant spending a lot of time learning how interactions with menus could be made and how to pick stuff up, how to get input from the controllers and ultimately how we put it together and make it work. Of course some of it was also spent overcoming one of the more challenging aspects of Virtual Reality, does it feel good? how do we transport people around without making them sick? Do they need a nose? all of these questions went into trying to make our game more comfortable for the player, and I think it worked. Generally I don't get motion sickness or anything like that, and so I relied on Noah's past experiences with Virtual Reality and how he approached these challenges.
The same thing can be said for FMOD, if you don't know already, FMOD is a very good tool that can be used to implement dynamic audio into games. That is things like 3-Dimensional audio, randomising pitch, ensuring that one sound cannot overpower others. At least that' what I know it can do for know. It's an awesome tool and I wish that I had learned of FMOD and how to operate it within Unity before this project, then I would have felt much better about the amount of audio actually implemented into the game.
These, I believe are the primary reasons why the product wasn't polished as well as it could be. While that sucks, it was an amazing learning process, and now that I have a basic level of understanding of both FMOD and VRTK, I cannot wait to develop for Virtual Reality again.
In terms of how our team worked, upon observation of we worked alongside with in our cohort. I can safely say that we were one of the safer teams. While it took a minuscule amount of time, I gained an understanding of the skill level and experiences of my team. By then I had been assigned as Project Manager, and had already set up modes of communication, a GitHub repository and task assigning within HackNPlan. Basically just kind of going through the motions of being a Project Manager. However, it was very inspiring to both my team and I that these things had already been set up and easy to access, it allowed us to all get down and dirty in documentation and setting up a baseline for our project. It felt great, both to have a team eager to have VR experience under their belt and an appropriate amount of experience.
Of course there are instances I can point out where the project took a turn for the worse, things like one of the programmers dedicating time to hooking up his own server to Unity in order to overcome the rate limiting and information restrictions of the default Unity analytics. Waiting for assets like audio and models to come in, and be ready to use. Having tasks be incomplete, or unsatisfactory, yet still put into the game anyway (I.E. the way that the combination lock is opened feels unintuitive and sub-par). Though like I said, overall I believe that the project was a success and the team worked well together.
The TL;DR of it is, I liked my team, we worked well, we worked relatively efficiently. A lot of the hiccups in development came from hesitation in design, and perhaps allocating time in the wrong areas. However, in the end, I loved working on this project, and I can't wait to do it again.