We made a lot of design progress over the summer, and put the pedal to the metal the last 2 weeks of the summer on the development side of things. After EAE day at the end of Spring 2015, we observed that most if not all of our players weren’t focused on the binaural audio cues of the game, but the visual feedback/input. We acknowledged it as a team after the event and agreed that was a design problem to tackle during the summer.
One of our most proactive producers got hired full-time at a studio during the summer, before we met in earnest, which was sad but also exciting for him. We would miss his hardwork and savvy but in a way it also allowed the team to reset roles and realize with a man down, we needed to focus and make deliberate decisions because time was of the essence.
Rohan (our original idea man and engineer extraordinaire) came up with the thought that we could give the player the most pertinent information they needed binaurally, unattached to a visual cue, e.g. a ghost leading through the level or telling you where danger was. He also realized that creating dynamic AI to lead a player through a variety of experiences would be very out of scope, not just for our mid-October IGF submission deadline, but also for our publish deadline at the end of spring in 2016. In his mind, it required either a single play experience, meaning the same path every play through, OR allowing another player to contribute and making it a cooperative experience.
He brought a prototype with a simple maze level with 2 players communicating via voice chat binaurally to our first meeting. As we all took turns playing this prototype, it was unanimous that everyone was much more excited to experience this iteration that any of our previous iterations. We agreed that this was the direction to go. From this iteration of one player without any kind of representation in the game, we iterated to our current experience, where one player cannot see and the other player cannot hear. While we try to avoid design by committee, it’s helped our entire team’s productivity that in our rare case, we have 100% team buy-in for our current mechanics and vision of the game.
As development continued during the summer, we ran into the problem of voice chat lag between players. I personally believed the time it would take to learn how to optimize the voice chat so that it wouldn’t lag would be too great, and we should find another solution. I proposed a simple pinging system. The communication would be ambiguous, but I thought that would also add to the experience of the game, because as we tested talking to each other on either side of the lab in the game, it was very easy to tell someone the exact steps to take and the exact degrees to turn to get through the level. After testing a branch with just pings for communication instead of voice chat, we came to a consensus to keep it in the final version of the game.
The final problem we had been tackling was that as the player without any visual input, the experience was quite boring. The last week before Fall semester began, Rohan and Viswanath came to a team meeting with a prototype of the blind player revealing enemies, and the deaf player being able to exterminate the enemy. This was another magical moment where the entire team had an opportunity to play and buy-in to this core mechanic to re-invigorate the enthusiasm for continuing development for our project.
During the second week of school, it was apparent that our enthusiasm surpassed our actual velocity. As the first sprint was wrapping up, very little had actually made it into our submission build. During our sprint review meeting, I had a serious conversation with the entire team about deadlines and the real scope of our IGF deadline. Someone brought up that the tasks they signed up for would never be done in just a sprint, which prompted a Scrum refresher about breaking down a larger task into sprint-sized bites, because they were responsible for only volunteering for work that could be done by a sprint. We also talked about how many of us have habits to take on more than we can chew because we think it is simply easier, but in reality that is under utilizing all of the resources we have and overall is slowly down our sprint velocity. It’s an interesting position to be in where it isn’t so much a problem of people not wanting to work or not wanting to be a part of the team, but wanting to do it all, with the best intentions.
Our next sprint review and build is on Thursday, so update forthcoming to see how much of the conversation needs to be reinforced. Repetition is the best teacher!