As said in a previous post about the Greenlight presentations (refer to that for what Greenlight even is), my team was chosen to continue development! I'm really proud of how much we were able to complete in those short 2 weeks of development prior to the presentations, and apparently others were impressed as well.
According to some of the people who were part of the selection process, Discarnate went through immediately and unanimously, which we were hoping for. My only qualm with that, however, is that I know for a fact that some of the people who voted to push Discarnate ahead didn't like it. Why would they feel pressured to vote for something they don't understand or like? Why wouldn't they raise those concerns and ask questions to the representative of the game? That made no sense to me, and my producer Ian was also a bit concerned by that. When people just automatically vote for something because it looks good or because progress was made, we lose so much critique value. Ian came back from the deliberations and was a bit disappointed because we got no useful feedback on what we can do better. We need some of that negative feedback! Please give it to us!
Greenlight cuts are a big stress factor for a lot of teams. Nobody wants to sink 40+ hours into a project, then have it be cut. I think our class did decently well with handling that often disappointing result, although I can't entirely speak for them since I didn't get cut. One of the things I really saw and learned from at Greenlight was the power of a clean, rehearsed presentation that has clearly been through critique. All of the teams in Kel's sections had really solid, engaging presentations even if the games being presented weren't as strong, and they were still received well by the crowd.
Since about half of the original teams get cut, that means there's a bunch of people who need to be redistributed. We added 5 more people to Rats with Hats a few weeks ago, and have been working towards laying down multiple pipelines, workflows, and structures to ensure that we're able to work efficiently with all these new people. So far, we've been working really well together, and we've come up with a good system for prototyping, then implementing, then polishing mechanics. We had a huge issue right off the bat, because we lost access to the Oculus Rift S headset we had been using for development. Around here, we call that bad, because our whole business plan was to target the Oculus store, and thus we had to use Oculus software within Unity. Now that we couldn't develop on Oculus, we had to make a switch to SteamVR and the VIVE system, so the first few weeks of our real development cycle with our bigger team was just getting to know each other, planning, and refactoring the existing project for SteamVR. I'm definitely happy to say that we've completed that goal, and then some! With the way we've organized ourselves, we were able to prototype the rest of the major mechanics for the level at the same time as the refactoring happened, all without crunching.
It's now been about 2 weeks of true development with 1 week of planning and on-boarding, and we're making good progress. We have a few of the more intense mechanics prototyped, one complete, and the Content team has been hard at work designing puzzles and making new assets. These next few sprints should fill out this level quite nicely, giving us a great environment with fun mechanics.
Personally, I've taken the role of lead programmer, and the Systems team lead. I'm responsible for organizing the Systems team meetings and sprint goals, as well as handling communication between the other leads, the Content team, and my own team to make sure everyone is on the same page with the same vision. Since all of the programmers are technically part of the Systems team, I'm able to fold those responsibilities together which is super nice. That's been my main contribution thus far, but this past sprint I also did the entire SteamVR refactor, getting the project back into working form. As a part of the refactor, I've also been writing documentation to describe how to use some of the new pieces of SteamVR. Coming up next, some hot-and-spicy sound effect systems and fluid physics!
Thanks for the read -- CS
Comments